From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23722 invoked from network); 2 May 2021 11:49:33 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 2 May 2021 11:49:33 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id E12789BD15; Sun, 2 May 2021 21:49:30 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 85E069BD01; Sun, 2 May 2021 21:48:17 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=planet.nl header.i=@planet.nl header.b="JZ+TS1A6"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id D1B609BD01; Sun, 2 May 2021 21:48:07 +1000 (AEST) Received: from cpsmtpb-ews03.kpnxchange.com (cpsmtpb-ews03.kpnxchange.com [213.75.39.6]) by minnie.tuhs.org (Postfix) with ESMTP id 3B95B9BCFF for ; Sun, 2 May 2021 21:47:59 +1000 (AEST) Received: from cpsps-ews12.kpnxchange.com ([10.94.84.179]) by cpsmtpb-ews03.kpnxchange.com with Microsoft SMTPSVC(8.5.9600.16384); Sun, 2 May 2021 13:47:53 +0200 X-Brand: 7abm2Q== X-KPN-SpamVerdict: e1=0;e2=0;e3=0;e4=;e6=(e1=10;e3=10;e2=11;e4=10;e6=1 0);EVW:White;BM:NotScanned;FinalVerdict:Clean X-CMAE-Analysis: v=2.4 cv=L+d+/8f8 c=1 sm=1 tr=0 ts=608e9169 cx=a_idp_e a=dZ5u/0G9QtS9WKCcNUBnHQ==:117 a=soxbC+bCkqwFbqeW/W/r+Q==:17 a=x1i13A_MHe4A:10 a=IkcTkHD0fZMA:10 a=5FLXtPjwQuUA:10 a=jEIl9BPeAAAA:8 a=ZFcCxvgQ0XuKHLeJfWcA:9 a=QEXdDO2ut3YA:10 a=UbykG2d9i8y_PxD0dgl3:22 X-CM-AcctID: kpn@feedback.cloudmark.com Received: from smtp.kpnmail.nl ([195.121.84.13]) by cpsps-ews12.kpnxchange.com over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Sun, 2 May 2021 13:47:53 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=planet.nl; s=planet01; h=message-id:to:date:subject:mime-version:content-type:from; bh=Q4Hd7OwXIqW/D01SBQMTNWOKaH8p6MjVdozh89cLrRY=; b=JZ+TS1A62s6DXlYkQ/L1ZSa6t9HCZvGSOYo22mOfPhFmACwkCuFh0Ri2HJRmpHiCyDys9wKk/rJ14 8E9SZ4I08jGTMNtq+QvrOvkTW7/KBrnGyHRhF83TnpmB+kg3wwX10SgTSvrRvSv6sQhPL1ssBz6nGd knyL66ChrWPiyMzc= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|9U2Udt7Qys6jD11C3kZWbcStx+vT8LmtM/OjCa+C+ir4dXo36ntq1Bn1eX6cBhx iPjEQJp+g0HQHjnVJG9rTLw== X-Originating-IP: 80.101.112.122 Received: from mba2.fritz.box (sqlite.xs4all.nl [80.101.112.122]) by smtp.kpnmail.nl (Halon) with ESMTPSA id 3a8fda18-ab3c-11eb-8208-005056998788; Sun, 02 May 2021 13:47:53 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sun, 2 May 2021 13:47:53 +0200 References: <61A97237-FBF7-4401-8971-266CE8E4A010@planet.nl> To: Clem Cole , TUHS main list In-Reply-To: Message-Id: <7ACDBEAE-B418-48F9-AE6D-ABD36F63C50C@planet.nl> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-OriginalArrivalTime: 02 May 2021 11:47:53.0826 (UTC) FILETIME=[FC90C420:01D73F48] X-RcptDomain: minnie.tuhs.org Subject: Re: [TUHS] Evolution of Unix (demand) paging 1980-1985 X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Paul Ruizendaal via TUHS Reply-To: Paul Ruizendaal Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" > On 1 May 2021, at 16:42, Clem Cole wrote: Thanks for that context Clem! =20 >> Is this implementation perhaps a derivative of John Reiser=E2=80=99s = work? > I don't know, but you might ask someone like Steve Rago, who I believe = was part of the implementation team. I did a bit more googling and this list and the AUUGN archive gave some = interesting results. It would seem that Keith Kellman and Steven Buroff = are the key people for more insight into the Reiser paging system (see = below for some quotes). Based on the below my hypothesis would be that when looking at the = surviving SYSV R2.4 paging code, Kellman and Buroff mainly added the = =E2=80=9CRegion=E2=80=9D abstraction (~900 sloc), and that the actual = paging (~1100 sloc) probably is a close derivative of the Reiser code. A more speculative hypothesis would be that moving that actual paging = code to SysIII, replacing the Region abstraction with the classic shared = text abstraction (as present since the V4 days), would result in = something close to what Rob and Norman recall. As you already pointed out, the paging code in R2.4 carries through to = R3 and is described in the Bach book. Paul =3D=3D=3D=3D TUHS list (Rob Pike, Aug 2019) I think it was slightly later. I joined mid-1980 and VAXes to replace = the 11/70 were being discussed but had not arrived. We needed to convert a = lab into a VAX machine room and decide between BSD and Reiser, all of which happened in the second half of 1980. Reiser Unix got demand paging a little later, and it was spectacularly fast. I remember being gobsmacked when I saw a demo in early 1981. Dead ends everywhere. =3D=3D=3D=3D TUHS list (Norman Wilson, Aug 2019) John Reiser did do his own paging system for UNIX 32/V. I heard about it from friends at Bell Labs ca. 1982-83, when I was still running systems for physicists at Caltech. It sounded very interesting, and I would love to have had my hands on it--page cache unified with buffer cache, copy-on-write from the start. The trouble is that Reiser worked in a different group from the original UNIX crowd, and his management didn't think his time well spent on that work, so it never got released. I remember asking, either during my interview at the Labs or after I started work there, why the 4.1 kernel had been chosen instead of Reiser's. It had to do with maintainability: there were already people who could come in and hack on the Berkeley system, as well as more using it and maintaining it, whereas Reiser's system had become a unicorn. Nobody in 1127 wanted to maintain a VM system or anything much close to the VAX hardware. So the decision was to stick with a kernel for which someone else would do those things. Once I'd been there for a year or so and settled in, I found that I was actually looking after all that stuff, because I was really interested in it. (Which seemed to delight a lot of people.) Would we have ended up using Reiser's kernel had I been there a couple of years earlier? I don't know. It is in any case a shame that jfr's code never saw the light of day. I really hope someone can find it on an old tape somewhere and we can get it into the archive, if only because I'd love to look at it. =3D=3D=3D=3D AUUGN Vol 5.1 (Keith Kellman, Dec 1983) Two research derivatives of the UNIX system have supported paging for = several years: Reiser 32V, and BSD. Work is under way at AT&T Bell Labs = to bring together the features of both of these systems [and others] to = form a demand paged kernel for UNIX System V. This talk will discuss = three areas of this work: requirements, architecture, and = implementation. The primary requirement of the paging system is that it be upward = compatible with its predecessor. This means that old objects must = execute unchanged, and that the meaning of system calls should not be = changed. For example, fork(2) should be made efficient rather than = inventing a new type of call. A second requirement is that the paging = system be based on a general machine-independent architecture. As part of the paging kernel development, a UNIX system memory = management architecture is being defined. The architecture is general = enough to support both paging and swapping kernels and many different = memory management units. The fundamental component of the architecture = is the "region." A region is a kernel data structure that represents a = potential virtual address space. The basic operations defined for = regions are: create/destroy, attach/detach, copy, change size, and load = a file. The defined architecture can support potential new UNIX system = features such as shared libraries and mapped files. =3D=3D=3D=3D AUUGN Vol 5.3 (Keith Kellman, Feb 1984) Work is currently underway at AT&T Bell Laboratories to develop a demand = paged kernel for UNIX System V. It is hoped that it will utilize the = best features of both 32V and BSD. Some of the requirements for the System V paging is that it will require = no program changes -- it will not change system calls. A priority is to = not hurt those who don=E2=80=99t need paging -- there should be no = performance loss. Also, as part of the development, there will be a = definition of memory management architecture -- the architecture must be = general enough to support many different memory management units, paging = and swapping kernels. A main component of the architecture is the = "region." A region is a data structure within a system that represents a = potential virtual address space. The reason for not merely supporting Berkeley paging is because AT&T = feels it is too complex and too specific to the VAX (not portable = enough). They also do not like the vfork call, and claim there is no = well-defined architecture. The status of the project is that there is currently a prototype = implemented on the 3B20 computer. The performance is good relative to = System V, Release 2. They are currently porting it to a VAX =3D=3D=3D=3D AUUGN Vol 5.6 (Steven Buroff, Nov 1984) Two research derivatives of the UNIX system have supported paging for = several years: Reiser 32V, and BSD. Work is under way at AT&T Bell Labs = to bring together the features of both of the systems [and others] to = form a demand paged kernel for UNIX System V. This talk will discuss = three areas of this work: requirements, architecture, and = implementation. The requirements are: there should be no user program changes for either = binary or source; the system must not hurt users who don=E2=80=99t = require paging, this means that if you want to use a paging system = because it is faster, then you can do so; and the system should provide = the capability of large address spaces if that is wanted. The idea was to generate a general model of memory management in the = UNIX kernel and to abstract all the code which deals with it into one = generalised set of routines. Different memory allocation methods can = then be used because a clean internal interface has been designed. The = main primitive in the design is a Region, which is an area of memory. It = can be shared or private and is manipulated by a set of well defined = operations. These operations are: create, delete, attach, detach, grow, = load and copy. The system allows copy on write by adroit use of the page = descriptors. =3D=3D=3D=3D