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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6809 invoked from network); 1 May 2021 14:43:35 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 1 May 2021 14:43:35 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id E16979BD3C; Sun, 2 May 2021 00:43:33 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id C757E9BD01; Sun, 2 May 2021 00:42:41 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b="im8Hs7Ae"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 169DC9BD01; Sun, 2 May 2021 00:42:35 +1000 (AEST) Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by minnie.tuhs.org (Postfix) with ESMTPS id 1FB079BCFF for ; Sun, 2 May 2021 00:42:34 +1000 (AEST) Received: by mail-qt1-f180.google.com with SMTP id 1so697799qtb.0 for ; Sat, 01 May 2021 07:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hP1E9UHXVj0yl0DZY8o03d5zjN73/Q6Ht5WRgUo9iuU=; b=im8Hs7AerZ2+RSXYsxWYaJnAzAhZ/TG1hEccOv7NqAWprXmXj4KSPH9DKqgjR2TZow CsB4mFrW2b1zBIqOQ4rO3kVnWVqRm+r5jxyZzGUt/eYc39U8jPXUmg0zTIj0rwlIn+Ow uug5VElmZxu0+wUMkI5tGbSqbgs5SIs2i3kHc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hP1E9UHXVj0yl0DZY8o03d5zjN73/Q6Ht5WRgUo9iuU=; b=jzcI6Yv0aJqMqTWpFsltocLtWBgPlumQe7megyUlIm1jOk9xGw1NTtrkJe3LB9pb4p usADIGOFyU4wRDAj2RxQUfpk3J66N+Dt1EwLIRXao+1GSNUCj3FQxG4ahSZWrJlV1Jgb GEUbFG+rhWzubvAgUuUekTDsVO73f65UkCyzrtXKxnDmzJCnRF703SvN0NPpLJZZiXg1 mWDUJz8K+LizsGWlZ/9/rPRxOZEgP8sr5Y1HAvG3352r72rjiINz59udVlFogLPBCoZm pMnbtAmvptXi+bY1DGXsK6DJQZy9eYAE03SXklbW4e3G5Wh/B0q7SZVC9cZwwmZVBHK1 DVpg== X-Gm-Message-State: AOAM5322+cNydN8B1R264Nah12bH2cEok1fefIGbsNbRCSrbWWCpZz8P 5RMZgxS7rMDgD8ZZZWZ+/J+KNYPwh9oepg1+8K2o1w== X-Google-Smtp-Source: ABdhPJyXIMKiClTCFDfapNm6JoRuZSjzLyWzr8G8CWpe1ZlzJeVg4XKcosDljSU6Nob6kWYR9XE4yCVr0zpLDasgC2U= X-Received: by 2002:a05:622a:1447:: with SMTP id v7mr9012901qtx.4.1619880152955; Sat, 01 May 2021 07:42:32 -0700 (PDT) MIME-Version: 1.0 References: <61A97237-FBF7-4401-8971-266CE8E4A010@planet.nl> In-Reply-To: <61A97237-FBF7-4401-8971-266CE8E4A010@planet.nl> From: Clem Cole Date: Sat, 1 May 2021 10:42:08 -0400 Message-ID: To: Paul Ruizendaal Content-Type: multipart/alternative; boundary="0000000000001897ca05c145bd25" 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: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000001897ca05c145bd25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, May 1, 2021 at 6:09 AM Paul Ruizendaal via TUHS < tuhs@minnie.tuhs.org> wrote: > Questions: > > Is that about correct, or am I missing major elements? > I'm going to stretch your time frame a little, but this is what I remember: SRV3 was an alternative that was more widely distributed than SVR2. This is described in Maury Bach's book. It was the basis that the VM in the Stellar machine (we would do a bit of a rewrite to make it reentrant and multi-threaded). SVR4 would eventually do that as well (not nearly as well in IMO - but alas Stellix is lost to winds I fear). Sun did their own, which Rob and Larry can describe. I don't think they cribbed much from anyone, but I would ask. DG/UX was a scratch kernel rewrote with its own VM code. Probably the nicest scheme I ever saw. Extremely clean and easy to understand the locks. I've often wondered what happened to that code case. It's too bad it not to be found these days. The CMU Mach code would be very widely used and is still in the wide in Mac OSx and iOS. Tru64 and the Intel paragon were also based on the system. By the time of the Linux VM, the Mach code was what many people were comparing things to. The Mach VM code was extremely flexible and could handle a number of different types of HW and paging/backing store schemes (had a 'plugin' called the pager) and of course worked well on SMP's from time t0, but if you look that codebase was huge and noted to be slow. Even when the OSF/1 and CMU folks created the Mach ukernel, it was a bit of joke as the Mach 386/uk was over 1.2M of memory before any of the servers started to run (at one point they talked about creating a nanokernel and moving the MMU code out of the UK but I don't think anyone ever did). The Chorus folks had something different yet that A&T was excited about as an alternative to Mach, but I don't think it went very far. > Several places mention that there was also a setup that was still swappin= g > in nature, but did not require allocations in core to be contiguous > (=E2=80=9Cscatter paging=E2=80=9D). Did this get used much in the era? > Depends on the code base and if the kernel could use the FS for paging or needed a dedicated paging file. In that era, most systems had a dedicated area (either disk partition or reserved file on the FS). If it uses the FS, then it tended to be able to handle the pages being scattered. We did that on Stellix and IIRC, DG could also. Masscomp and the Intel Paragon did not because predictable performance on a fault was important, although Masscomp cheated later on since we had contiguous files support and eventually allow those files to be used for paging also. > At first glance, the SysV R2 code seems shorter and cleaner than the earl= y > BSD code (~2000 vs. ~3000 sloc). At the time, the SysV VM code was often considered easier to work, a tad less Vax dependent. Which again, ask Rob or Larry, I think is why Sun rewrote the BSD for their use. We used a BSD base at Masscomp because it worked, but ... Tom, Terry, and I had long memories of making the original BSD code MP-safe for the MC-500/DP [which was the first commercial MP UNIX]. So by Stellar time, since we had a 'do over,' we started with the SVR3 code and thread it for exactly this reason. > 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. =E1=90=A7 --0000000000001897ca05c145bd25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On S= at, May 1, 2021 at 6:09 AM Paul Ruizendaal via TUHS <tuhs@minnie.tuhs.org> wrote:
Que= stions:

Is that about correct, or am I missing major elements?
I'm going to stretch your time frame= a little, but this is what I remember:

=C2=A0
= SRV3 was an alternative that was more widely distri= buted than SVR2.=C2=A0 This is described in Maury Bach's book.=C2=A0 = =C2=A0It was the basis that the VM in the Stellar machine (we would do a bi= t of a rewrite to make it reentrant and multi-threaded).=C2=A0 =C2=A0SVR4 w= ould eventually do that as well (not nearly as well in IMO - but alas Stell= ix is lost to=C2=A0winds I fear).

Sun d= id their own, which Rob and Larry can describe.=C2=A0 I don't think the= y cribbed much from anyone, but I would ask.

DG/UX was a scratch kernel rewrote with its own VM code.=C2=A0 Probably= =C2=A0the nicest scheme I ever saw.=C2=A0 =C2=A0Extremely=C2=A0clean and ea= sy to understand the locks.=C2=A0 I've often wondered what happened to = that code case.=C2=A0 It's too bad it not to be found these days.

The CMU Mach code would be very widely used an= d is still in the wide in Mac OSx and iOS.=C2=A0 =C2=A0Tru64 and the Intel = paragon were also based on the system.

By the time o= f the Linux=C2=A0VM, the Mach code was what many people were comparing thin= gs to.=C2=A0 =C2=A0The Mach VM code was extremely flexible and could handle= a number of different types of HW and paging/backing store schemes (had a = 'plugin' called the pager) and of course worked well on SMP's f= rom time t0, but if you look that codebase was huge and noted to be slow.= =C2=A0 =C2=A0Even when the=C2=A0OSF/1 and CMU folks created the Mach ukerne= l, it was a bit of joke as the Mach 386/uk was over 1.2M of memory before a= ny of the servers started to run (at one point they talked about creating a= nanokernel and moving the MMU code out of the UK but I don't think any= one ever did).=C2=A0=C2=A0

The Chorus folks had something differe= nt yet that A&T was excited about as an alternative to Mach, but I don&= #39;t think it went very far.


Several places mention that there was also a setup that was still swapping = in nature, but did not require allocations in core to be contiguous (=E2=80= =9Cscatter paging=E2=80=9D). Did this get used much in the era?
<= /blockquote>
Depends on the code base and i= f the kernel could use the FS for paging or needed a dedicated paging file.= =C2=A0 =C2=A0In that era, most systems had a dedicated area (either disk pa= rtition or reserved file on the FS).=C2=A0 If it uses the FS, then it tende= d to be able to handle the pages being scattered.=C2=A0 =C2=A0We did that o= n Stellix=C2=A0and IIRC, DG could also.

M= asscomp and the Intel Paragon did not because predictable performance on a = fault was important, although Masscomp cheated later on since we had contig= uous=C2=A0files support and eventually allow those files to be used for pag= ing also.
=C2=A0
At first glance= , the SysV R2 code seems shorter and cleaner than the early BSD code (~2000= vs. ~3000 sloc).
At the= time, the SysV VM code was often considered easier to work, a tad less Vax= dependent.=C2=A0 Which again, ask Rob or Larry, I think is why Sun rewrote= the BSD for their use.=C2=A0 =C2=A0We used a BSD base at Masscomp because = it worked, but ... Tom, Terry, and I had long memories of making the origin= al BSD code MP-safe for the MC-500/DP [which was the first commercial MP UN= IX].=C2=A0 =C2=A0So=C2=A0by Stellar time, since we had a 'do= over,' we started with the SVR3 code and thread it for=C2=A0exactly th= is reason.=C2=A0
=C2=A0
Is this impl= ementation perhaps a derivative of John Reiser=E2=80=99s work?
I do= n't know, but you might ask someone=C2=A0like Steve Rago, who I believe= was part of the implementation team.
3D""=E1= =90=A7
--0000000000001897ca05c145bd25--