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, HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29606 invoked from network); 7 Jan 2022 19:02:23 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 7 Jan 2022 19:02:23 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 123BC9CFBB; Sat, 8 Jan 2022 05:02:21 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 83A949CF62; Sat, 8 Jan 2022 05:01:47 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=bsdimp-com.20210112.gappssmtp.com header.i=@bsdimp-com.20210112.gappssmtp.com header.b="AI02yRAo"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id B74C59CF62; Sat, 8 Jan 2022 05:01:43 +1000 (AEST) Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) by minnie.tuhs.org (Postfix) with ESMTPS id B59899CF2D for ; Sat, 8 Jan 2022 05:01:42 +1000 (AEST) Received: by mail-ua1-f44.google.com with SMTP id o1so11917660uap.4 for ; Fri, 07 Jan 2022 11:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/5OpQDu60FaTnXxQyJEbjYhzehCKI+8ZjvY4luL9NnQ=; b=AI02yRAoX/54CYrVMdZB0fUaw6Nwwx35joGDznzXqaK2rdX9SV9EZOEVfIF1IphSdY 3extCXQ2I7YeXYxTyigT9ePhWKMGwEDyi1XfSOCVzMYM5w3zZzmrHTywoiUldTQfvtx4 hsedCpoIKkpe7R5iA+nfpLuruXw0zatfHTk+FzC4AGw3oW/M8BY6ygL1R+Kf6jpq+trm XuK5XFweS50NL+pJJqYqcFQWQd7oLeAHIcUEfXtt/uVN6Q0xxrYM3bo0lKSXjIalOZCD Z1O2J/KPL+ihoj9njsriweX97TdZ9czH9kqoXm1sdBFxaB1WiaIKa7w9dHLlBXZXxcel etdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/5OpQDu60FaTnXxQyJEbjYhzehCKI+8ZjvY4luL9NnQ=; b=QH+sLmHcfDoc5MDRhxSpH2PM13gc4OugQNQeW7f41zeEIUQ7PfSsyOU7fyCU4Sjqd+ sq6UYXMt3N/vcy3nS1uaxqnxTNrBQh44FgPVxzMLL4f0Ei47TisMqFlMWkliZlEJHOgF IGsoGDgVI+nI7dVMgTEOE1T9575e+2sT/kZoR/nAQwqMReawaHWftQdQwc1sVTHIV1df /eTarOWmOj40d5u1TVrWAngBDAESzyGtM6pO6js19KhsbLRAgm0uZxv8zEPwVc/4FPgc g/XdarsWt9tQaEJVGkdNZGYzlQ4qZkthbHPA0ZKItyC+IJois1AZSt4vn+kp9+KWE1k8 kIDA== X-Gm-Message-State: AOAM5326Wl2fnZIJuJ46A7YJrm7A+s1PUm7NBklafpSHabB5E05374+5 EaH0Nb5TfrLFk5gxOyoKCu5LbVgRGHQrYCbyPUQC7S0YjQ8= X-Google-Smtp-Source: ABdhPJzSv4aS/RzeCs5iP3e/BMXPN69XW+/8qM91xR+ne4vyKCTnmLB5C+YyTVx9DhDfPMGA6UOlyvoByZ1xvUBtl1M= X-Received: by 2002:a67:f8cb:: with SMTP id c11mr22118805vsp.13.1641582101644; Fri, 07 Jan 2022 11:01:41 -0800 (PST) MIME-Version: 1.0 References: <97f563fa-5a17-424b-acc6-07cf127f496d@localhost> <20220103234411.GA19828@mcvoy.com> <20220103235600.GA68567@eureka.lemis.com> In-Reply-To: <20220103235600.GA68567@eureka.lemis.com> From: Warner Losh Date: Fri, 7 Jan 2022 12:01:30 -0700 Message-ID: To: "Greg 'groggy' Lehey" Content-Type: multipart/alternative; boundary="00000000000009dc7005d5029e50" Subject: Re: [TUHS] SMP: BSD vs System V (once was: moving directories in svr2) 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: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000009dc7005d5029e50 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 3, 2022 at 5:03 PM Greg 'groggy' Lehey wrote: > On Monday, 3 January 2022 at 15:44:11 -0800, Larry McVoy wrote: > > On Mon, Jan 03, 2022 at 05:21:51PM -0600, Doug McIntyre wrote: > >> On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote: > >> I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1 > was quite usable and stable. > >> Also by this time, the hardware was going in directions that SunOS > wouldn't keep up with. > > > > Yeah, Doug is right, SunOS was pretty simple, it didn't really take > advantage > > of SMP, Greg Limes tried to thread it but it was too big a job for one > guy. > > > > That's not to say that SunOS couldn't have evolved into SMP, I'm 100% > > sure it could have. It just didn't. It's a shame. > > An interesting question. I had always thought that SMP was (one of?) > the technical reasons why Sun moved from a BSD to a System V base. > Since then, of course, we've done lots of work on SMP support for at > least FreeBSD. Does anybody have an overview of how good the support > is compared to modern Solaris? Is there any intrinsic reason why one > should be better than the other? > So, there were several groups that added SMP to BSD or SunOS. Solbourne's OS/MP added MP to SunOS 4.0 as first ASMP (one CPU did all the system calls, but jobs could run on other CPUs) and later as SMP (first as any CPU could run the system calls, but there was global lock and later each subsystem had a lock that it ran with). Later versions improved locking granularity by pushing locks down and making things finer grained. SunOS was a 4.3BSD with its own VM system that was well suited for locking. There were other efforts to do this, but none of them made it back to the Berkeley mother ship, so 4.4BSD shipped w/o MP support in any real sense in 1993. System V got MP when a consortium of vendors added it to the 4.0 release (that didn't include sun). By 1992 this was rolled into the 4.2 release that AT&T did with Novell. This is what would serve as the basis for Sun's Solaris product line. FreeBSD, NetBSD, OpenBSD and Dragonfly BSD have all done MP in different ways since then, of course, and Linux has added MP as well early on. So in a very real sense, Sun was in a position where it had to re-do the work that David Barak and others did at Solbourne to lock the SunOS kernel (work which really took years to complete and stabilize), or they had to go with a solution that was already developed. AT&T had that with System V 4.x, and Berkeley didn't have an equivalent set of functionality for them to draw from. I think from a PHB perspective, the decision was easy, mostly because they vastly under-estimated the maturity of System Vr4.2's MP support (but I wasn't in the room: I was at Solbourne which would never have licensed its OS/MP to Sun due to the... competitive atmosphere at the time and likely NIH inside of Sun for adopting that). Warner --00000000000009dc7005d5029e50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 3, 2022 at 5:03 PM Greg &= #39;groggy' Lehey <grog@lemis.com<= /a>> wrote:
O= n Monday,=C2=A0 3 January 2022 at 15:44:11 -0800, Larry McVoy wrote:
> On Mon, Jan 03, 2022 at 05:21:51PM -0600, Doug McIntyre wrote:
>> On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote:
>> I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, bu= t 2.5.1 was quite usable and stable.
>> Also by this time, the hardware was going in directions that SunOS= wouldn't keep up with.
>
> Yeah, Doug is right, SunOS was pretty simple, it didn't really tak= e advantage
> of SMP, Greg Limes tried to thread it but it was too big a job for one= guy.
>
> That's not to say that SunOS couldn't have evolved into SMP, I= 'm 100%
> sure it could have.=C2=A0 It just didn't.=C2=A0 It's a shame.<= br>
An interesting question.=C2=A0 I had always thought that SMP was (one of?)<= br> the technical reasons why Sun moved from a BSD to a System V base.
Since then, of course, we've done lots of work on SMP support for at least FreeBSD.=C2=A0 Does anybody have an overview of how good the support<= br> is compared to modern Solaris?=C2=A0 Is there any intrinsic reason why one<= br> should be better than the other?


=
with Novell. This is what would serve as the basis for Sun's Solar= is product line.

FreeBSD, NetBSD, OpenBSD and Drag= onfly BSD have all done MP in different
ways since then, of cours= e, and Linux has added MP as well early on.

So in = a very real sense, Sun was in a position where it had to re-do the work
that David Barak and others did at Solbourne to lock the SunOS kerne= l (work
which really took years to complete and stabilize), or th= ey had to go with a solution
that was already developed. AT&T= had that with System V 4.x, and Berkeley didn't
have an equi= valent set of functionality for them to draw from. I think from a PHB
=
perspective, the decision was easy, mostly because they vastly under-e= stimated
the maturity of System Vr4.2's MP support (but I was= n't in the room: I was at Solbourne
which would never have li= censed its OS/MP to Sun due to the... competitive atmosphere
at t= he time and likely NIH inside of Sun for adopting that).

Warner
--00000000000009dc7005d5029e50--