From owner-freebsd-smp Mon Jun 3 19:30:27 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA06029 for smp-outgoing; Mon, 3 Jun 1996 19:30:27 -0700 (PDT) Received: from MindBender.HeadCandy.com (root@[199.238.225.168]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA06023 for ; Mon, 3 Jun 1996 19:30:22 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.HeadCandy.com (8.7.5/8.6.9) with SMTP id TAA18786 for ; Mon, 3 Jun 1996 19:29:47 -0700 (PDT) Message-Id: <199606040229.TAA18786@MindBender.HeadCandy.com> X-Authentication-Warning: MindBender.HeadCandy.com: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: freebsd-smp@freebsd.org Subject: SMP progress? Date: Mon, 03 Jun 1996 19:29:46 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At the risk of asking a st00pid FAQ question, what is the current state of progress on FreeBSD SMP work? I'm thinking about picking up a dual-Pentium 100MHz MB (I already have one of the chips -- will just buy a second with the MB) in a month or so with the intent of dabbling in SMP Unix (BSD of course). I can run Windows NT on it easily enough, but what fun would that be? :-) Besides, I'll have a 200MHz P5 (single-CPU) for NT by then, anyway... That should be good enough for Descent II and Mech Warrier 2... :-) ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@HeadCandy.com --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... Roll your own Internet access -- Seattle People's Internet cooperative. If you're in the Seattle area, ask me how. ----------------------------------------------------------------------------- From owner-freebsd-smp Tue Jun 4 11:33:27 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA02469 for smp-outgoing; Tue, 4 Jun 1996 11:33:27 -0700 (PDT) Received: from critter2.tfs.com ([140.145.16.108]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA02463; Tue, 4 Jun 1996 11:33:23 -0700 (PDT) Received: from critter2.tfs.com (localhost [127.0.0.1]) by critter2.tfs.com (8.7.5/8.7.3) with ESMTP id LAA00562; Tue, 4 Jun 1996 11:32:37 -0700 (PDT) To: "Michael L. VanLoon -- HeadCandy.com" cc: freebsd-smp@freebsd.org Subject: Re: SMP progress? In-reply-to: Your message of "Mon, 03 Jun 1996 19:29:46 PDT." <199606040229.TAA18786@MindBender.HeadCandy.com> Date: Tue, 04 Jun 1996 11:32:36 -0700 Message-ID: <560.833913156@critter2.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > At the risk of asking a st00pid FAQ question, what is the current > state of progress on FreeBSD SMP work? Pretty good, quite stable. > I'm thinking about picking up a dual-Pentium 100MHz MB (I already have > one of the chips -- will just buy a second with the MB) in a month or > so with the intent of dabbling in SMP Unix (BSD of course). I can run > Windows NT on it easily enough, but what fun would that be? :-) go for it! -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Tue Jun 4 13:55:55 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12836 for smp-outgoing; Tue, 4 Jun 1996 13:55:55 -0700 (PDT) Received: from MindBender.HeadCandy.com (root@[199.238.225.168]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA12825 for ; Tue, 4 Jun 1996 13:55:49 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.HeadCandy.com (8.7.5/8.6.9) with SMTP id NAA23549 for ; Tue, 4 Jun 1996 13:55:43 -0700 (PDT) Message-Id: <199606042055.NAA23549@MindBender.HeadCandy.com> X-Authentication-Warning: MindBender.HeadCandy.com: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: freebsd-smp@freebsd.org Subject: Unix/NT synchronization model (was: SMP progress?) In-reply-to: Your message of Tue, 04 Jun 96 11:32:36 -0700. <560.833913156@critter2.tfs.com> Date: Tue, 04 Jun 1996 13:55:43 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> At the risk of asking a st00pid FAQ question, what is the current >> state of progress on FreeBSD SMP work? >Pretty good, quite stable. So, where are SMP development issues discussed? I didn't see a lot of traffic in this group in the archives. Another question I have: What is the "reference" model for SMP synchronization methods in Unix? Solaris? OSF/1? For those who are familiar with the Windows NT synchronization model, how does this Unix reference model compare? I. e. what are the similarties and differences? I've only done real threads and SMP-aware code on Windows NT, so don't have any point of reference for this kind of work on Unix. For what it's worth, in my somewhat limited experience, the NT model seems to be pretty well designed (well, ignoring the fact that it's surrounded by the Win32 API... :-). ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@HeadCandy.com --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... Roll your own Internet access -- Seattle People's Internet cooperative. If you're in the Seattle area, ask me how. ----------------------------------------------------------------------------- From owner-freebsd-smp Tue Jun 4 14:07:07 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA13764 for smp-outgoing; Tue, 4 Jun 1996 14:07:07 -0700 (PDT) Received: from critter.tfs.com ([140.145.16.108]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA13740; Tue, 4 Jun 1996 14:07:01 -0700 (PDT) Received: from critter.tfs.com (localhost [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id OAA01370; Tue, 4 Jun 1996 14:06:27 -0700 (PDT) To: "Michael L. VanLoon -- HeadCandy.com" cc: freebsd-smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) In-reply-to: Your message of "Tue, 04 Jun 1996 13:55:43 PDT." <199606042055.NAA23549@MindBender.HeadCandy.com> Date: Tue, 04 Jun 1996 14:06:26 -0700 Message-ID: <1368.833922386@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > >> At the risk of asking a st00pid FAQ question, what is the current > >> state of progress on FreeBSD SMP work? > > >Pretty good, quite stable. > > So, where are SMP development issues discussed? I didn't see a lot of > traffic in this group in the archives. in smp@freebsd.org, there isn't much traffic :-) > Another question I have: What is the "reference" model for SMP > synchronization methods in Unix? Solaris? OSF/1? For those who are > familiar with the Windows NT synchronization model, how does this Unix > reference model compare? I. e. what are the similarties and > differences? To Be Decided really... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Tue Jun 4 15:00:57 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA17677 for smp-outgoing; Tue, 4 Jun 1996 15:00:57 -0700 (PDT) Received: from MindBender.HeadCandy.com (root@[199.238.225.168]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA17670 for ; Tue, 4 Jun 1996 15:00:52 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.HeadCandy.com (8.7.5/8.6.9) with SMTP id PAA23901; Tue, 4 Jun 1996 15:00:45 -0700 (PDT) Message-Id: <199606042200.PAA23901@MindBender.HeadCandy.com> X-Authentication-Warning: MindBender.HeadCandy.com: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: Poul-Henning Kamp cc: freebsd-smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) In-reply-to: Your message of Tue, 04 Jun 96 14:06:26 -0700. <1368.833922386@critter.tfs.com> Date: Tue, 04 Jun 1996 15:00:44 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Another question I have: What is the "reference" model for SMP >> synchronization methods in Unix? Solaris? OSF/1? For those who are >> familiar with the Windows NT synchronization model, how does this Unix >> reference model compare? I. e. what are the similarties and >> differences? >To Be Decided really... Maybe "reference model" was too strong. Where do most of you get your ideas for what SMP synchronization should look like in FreeBSD? From Solaris? OSF/1? Somewhere else? Since my only threaded/multi-CPU-aware code has all been written in Windows NT, I'd like to find out what a "good" Unix synchronization implementation looks like. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@HeadCandy.com --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... Roll your own Internet access -- Seattle People's Internet cooperative. If you're in the Seattle area, ask me how. ----------------------------------------------------------------------------- From owner-freebsd-smp Tue Jun 4 15:05:43 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA17989 for smp-outgoing; Tue, 4 Jun 1996 15:05:43 -0700 (PDT) Received: from critter.tfs.com ([140.145.16.108]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA17976; Tue, 4 Jun 1996 15:05:32 -0700 (PDT) Received: from critter.tfs.com (localhost [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id PAA01829; Tue, 4 Jun 1996 15:05:03 -0700 (PDT) To: "Michael L. VanLoon -- HeadCandy.com" cc: freebsd-smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) In-reply-to: Your message of "Tue, 04 Jun 1996 15:00:44 PDT." <199606042200.PAA23901@MindBender.HeadCandy.com> Date: Tue, 04 Jun 1996 15:05:02 -0700 Message-ID: <1827.833925902@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Reply-to: phk@freebsd.org In message <199606042200.PAA23901@MindBender.HeadCandy.com>, "Michael L. VanLoo n -- HeadCandy.com" writes: > >>> Another question I have: What is the "reference" model for SMP >>> synchronization methods in Unix? Solaris? OSF/1? For those who are >>> familiar with the Windows NT synchronization model, how does this Unix >>> reference model compare? I. e. what are the similarties and >>> differences? > >>To Be Decided really... > >Maybe "reference model" was too strong. Where do most of you get your >ideas for what SMP synchronization should look like in FreeBSD? From >Solaris? OSF/1? Somewhere else? > >Since my only threaded/multi-CPU-aware code has all been written in >Windows NT, I'd like to find out what a "good" Unix synchronization >implementation looks like. As in "I expect your guys to know this before you even try it ?" Frankly, we havn't spent much time seriously persuing this issue. If you have input, we're most open to it... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Tue Jun 4 15:25:18 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA19187 for smp-outgoing; Tue, 4 Jun 1996 15:25:18 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA19174 for ; Tue, 4 Jun 1996 15:25:11 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id PAA15769; Tue, 4 Jun 1996 15:25:10 -0700 Date: Tue, 4 Jun 1996 15:25:10 -0700 From: Sean Eric Fagan Message-Id: <199606042225.PAA15769@kithrup.com> To: smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) Newsgroups: kithrup.freebsd.smp In-Reply-To: <1827.833925902.kithrup.freebsd.smp@critter.tfs.com> References: Your message of "Tue, 04 Jun 1996 15:00:44 PDT." <199606042200.PAA23901@MindBender.HeadCandy.com> Organization: Kithrup Enterprises, Ltd. Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <1827.833925902.kithrup.freebsd.smp@critter.tfs.com> you write: >Reply-to: phk@freebsd.org >As in "I expect your guys to know this before you even try it ?" > >Frankly, we havn't spent much time seriously persuing this issue. Well, that's not *quite* true ;). Right now, it's going for extremely low-grained MP support -- only one processor can be in kernel mode at a time. If/when the secondary processor(s) can take an interrupt, it will probably have reached that goal, and will manage to improve performance. Okay, so that's an extremely short-ranged goal ;). But I don't expect true symmetric MP to be happening for quite some time yet -- there's just too much that would have to be changed. (Locks around nearly every structure reference in the kernel, for example.) Sean. From owner-freebsd-smp Tue Jun 4 15:35:47 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA19856 for smp-outgoing; Tue, 4 Jun 1996 15:35:47 -0700 (PDT) Received: from critter.tfs.com ([140.145.16.108]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA19848; Tue, 4 Jun 1996 15:35:40 -0700 (PDT) Received: from critter.tfs.com (localhost [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id PAA01928; Tue, 4 Jun 1996 15:35:09 -0700 (PDT) To: Sean Eric Fagan cc: smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) In-reply-to: Your message of "Tue, 04 Jun 1996 15:25:10 PDT." <199606042225.PAA15769@kithrup.com> Date: Tue, 04 Jun 1996 15:35:08 -0700 Message-ID: <1926.833927708@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199606042225.PAA15769@kithrup.com>, Sean Eric Fagan writes: > >Okay, so that's an extremely short-ranged goal ;). But I don't expect true >symmetric MP to be happening for quite some time yet -- there's just too >much that would have to be changed. (Locks around nearly every structure >reference in the kernel, for example.) And it may not actually >improve< performance to do so... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Tue Jun 4 16:21:02 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA21745 for smp-outgoing; Tue, 4 Jun 1996 16:21:02 -0700 (PDT) Received: from MindBender.HeadCandy.com (root@[199.238.225.168]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA21740 for ; Tue, 4 Jun 1996 16:20:54 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.HeadCandy.com (8.7.5/8.6.9) with SMTP id QAA24168; Tue, 4 Jun 1996 16:16:46 -0700 (PDT) Message-Id: <199606042316.QAA24168@MindBender.HeadCandy.com> X-Authentication-Warning: MindBender.HeadCandy.com: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: Sean Eric Fagan cc: smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) In-reply-to: Your message of Tue, 04 Jun 96 15:25:10 -0700. <199606042225.PAA15769@kithrup.com> Date: Tue, 04 Jun 1996 16:16:46 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >In article <1827.833925902.kithrup.freebsd.smp@critter.tfs.com> you write: >>Reply-to: phk@freebsd.org >>Frankly, we havn't spent much time seriously persuing this issue. >Right now, it's going for extremely low-grained MP support -- only one >processor can be in kernel mode at a time. If/when the secondary >processor(s) can take an interrupt, it will probably have reached that goal, >and will manage to improve performance. Well, that's all very interesting... (I mean really -- thanks for the info) But maybe I'm not stating myself clearly. :-) What I'm really after is recommendations on where I should look if I want to see how another SMP Unix implements synchronization controls. I just want to find out how other people have implemented it. All I know is Windows NT (SMP, not in general, of course), and I want to see a contrasting implementation. For example, if I were to go find an OSF/1 (Digital Unix) system and play around with it, would that be a good representation place to start? Or would someone say "Oh no! Don't look at Digital Unix -- it's SMP support really sucks!" :-) I'm just looking for peoples' ideas and opinions here -- not an over-riding edict. Tell me what your favorite Unix SMP system is... ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@HeadCandy.com --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... Roll your own Internet access -- Seattle People's Internet cooperative. If you're in the Seattle area, ask me how. ----------------------------------------------------------------------------- From owner-freebsd-smp Tue Jun 4 16:24:45 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA21899 for smp-outgoing; Tue, 4 Jun 1996 16:24:45 -0700 (PDT) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA21893 for ; Tue, 4 Jun 1996 16:24:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.7.5/8.6.5) with SMTP id QAA00541; Tue, 4 Jun 1996 16:24:36 -0700 (PDT) Message-Id: <199606042324.QAA00541@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost [127.0.0.1] didn't use HELO protocol To: Sean Eric Fagan cc: smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) In-reply-to: Your message of "Tue, 04 Jun 1996 15:25:10 PDT." <199606042225.PAA15769@kithrup.com> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 04 Jun 1996 16:24:35 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Okay, so that's an extremely short-ranged goal ;). But I don't expect true >symmetric MP to be happening for quite some time yet -- there's just too >much that would have to be changed. (Locks around nearly every structure >reference in the kernel, for example.) What do you mean by "true symmetric MP"? The current stuff is "true SMP". Just because it is coarse-grained, doesn't mean it isn't SMP. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-smp Tue Jun 4 16:37:12 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA22928 for smp-outgoing; Tue, 4 Jun 1996 16:37:12 -0700 (PDT) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA22920 for ; Tue, 4 Jun 1996 16:37:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.7.5/8.6.5) with SMTP id QAA00591; Tue, 4 Jun 1996 16:36:52 -0700 (PDT) Message-Id: <199606042336.QAA00591@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost [127.0.0.1] didn't use HELO protocol To: "Michael L. VanLoon -- HeadCandy.com" cc: Sean Eric Fagan , smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) In-reply-to: Your message of "Tue, 04 Jun 1996 16:16:46 PDT." <199606042316.QAA24168@MindBender.HeadCandy.com> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 04 Jun 1996 16:36:52 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >For example, if I were to go find an OSF/1 (Digital Unix) system and >play around with it, would that be a good representation place to >start? Or would someone say "Oh no! Don't look at Digital Unix -- >it's SMP support really sucks!" :-) I'm just looking for peoples' >ideas and opinions here -- not an over-riding edict. Tell me what >your favorite Unix SMP system is... You may want to take a look at Mach's SMP locking and structure. It's not exactly what we'll be doing in FreeBSD, but it's not a too-bad example. Of course Mach is a microkernel design, but just overlook that while you're looking at the SMP related stuff. :-) Early SMP versions of just about every SMP Unix OS I know of started out being a single lock and became fine-grained in subsequant versions (in many cases before the code was officially released). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-smp Tue Jun 4 16:53:05 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA23693 for smp-outgoing; Tue, 4 Jun 1996 16:53:05 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA23687; Tue, 4 Jun 1996 16:53:03 -0700 (PDT) Message-Id: <199606042353.QAA23687@freefall.freebsd.org> To: "Michael L. VanLoon -- HeadCandy.com" cc: Sean Eric Fagan , smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) In-reply-to: Your message of "Tue, 04 Jun 1996 16:16:46 PDT." <199606042316.QAA24168@MindBender.HeadCandy.com> Date: Tue, 04 Jun 1996 16:53:02 -0700 From: "Justin T. Gibbs" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >But maybe I'm not stating myself clearly. :-) What I'm really after is >recommendations on where I should look if I want to see how another >SMP Unix implements synchronization controls. I just want to find out >how other people have implemented it. All I know is Windows NT (SMP, >not in general, of course), and I want to see a contrasting >implementation. Aren't you really asking about thread and process syncronization? This is an issue regardless of whether the system is SMP. I've also only dealt with the NT implementations of critical sections and mutexes, and unlike the rest of the win32 API, it seems they did a fairly good job of it (although there are some additional scheduling controls I wish were provided). >----------------------------------------------------------------------------- > Michael L. VanLoon michaelv@HeadCandy.com > --< Free your mind and your machine -- NetBSD free un*x >-- > NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, > Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... > NetBSD ports in progress: PICA, others... > > Roll your own Internet access -- Seattle People's Internet cooperative. > If you're in the Seattle area, ask me how. >----------------------------------------------------------------------------- -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-smp Tue Jun 4 17:05:53 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA24190 for smp-outgoing; Tue, 4 Jun 1996 17:05:53 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA24184; Tue, 4 Jun 1996 17:05:48 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA27740; Tue, 4 Jun 1996 17:01:14 -0700 From: Terry Lambert Message-Id: <199606050001.RAA27740@phaeton.artisoft.com> Subject: Re: Unix/NT synchronization model (was: SMP progress?) To: phk@freebsd.org (Poul-Henning Kamp) Date: Tue, 4 Jun 1996 17:01:14 -0700 (MST) Cc: sef@kithrup.com, smp@freebsd.org In-Reply-To: <1926.833927708@critter.tfs.com> from "Poul-Henning Kamp" at Jun 4, 96 03:35:08 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Okay, so that's an extremely short-ranged goal ;). But I don't expect true > >symmetric MP to be happening for quite some time yet -- there's just too > >much that would have to be changed. (Locks around nearly every structure > >reference in the kernel, for example.) > > And it may not actually >improve< performance to do so... Actually, I disagree with this. I think that the higher grain the parallelism, the better the scalability. As far as UP performance is concerned, the syncronization points should be macrotized, but I'd expect them to go down to spinlocks, at most, in the UP case, not compile out altogether. The reason I say this is that there are significant performance wins to kernel multithreading. When we (Novell/USG) implemented kernel multithreading and UFS reentrancy on top of kernel multithreading, there was a 160% performance increase in the UP case, even with the addition heavy-weight (cache flushing for interprocessor synchronization) mutexes instead of semaphores or spinlocks. In other words, the multithreading *more* than paid for the high-grained synchronization overhead. I would like to see a modified version of a combined Sequent/SVR4 model for high grain parallelism. The SVR4/Solaris model is the model described in "UNIX for Modern Architectures" whenever a specific implementation is referenced. The problem with the vanilla SVR4/Solaris model is the use of the SLAB allocator. Vahalia loves this allocator ("UNIX Internals: The New Frontiers"), but it is adequate for scaling only to the point of bus-loading with synchronization traffic. A SLAB allocator is a modified zone allocator (like that used in MACH) that preallocates pages into zones so that like objects are stored in like areas... if you use a sufficient granularity for your zones, then this resolves the high/medium/low persistance object issues that a simple zone allocator can't address (ie: minimizing kernel heap fragmentation -- a problem all of the BSD implementations currently suffer under -- Linux, too, for that matter). The Sequent model, by contrast, uses a per-processor page pool and pulls allocations from those pools (using zone allocation... yes, I agree that this is not efficient, it's not relevent to the benefits of a per processor page pool). The win on a per processor page pool is that a hierarchical lock management scheme allows allocation on a per processor basis without having to grab the global mutex (and therefore having to synchronize cache caontents for the mutex data area between processors). For mutex pages, this means that there is significant benefit to simply marking the pages as non-cacheable, since the reload frequency is dropped. The downside is that this requires a hierarchical lock manager which implements intention modes: you need to implement six modes (R W X IR IW IX) instead of threee (R W X). The benfit here is that it is now possible to lock IX the per processor mutex implemented as a counting semaphore in a non-cached page, and compute deadlock without reference to other processors. The internal nodes under the per processr lock node can be in processor-local (cacheable) pages, so locality is not sacraficed (as it would be in the SVR4/Solaris model by the need to flush *all* the pages from the cache, or to mark them non-cacheable). The whole point of this exercise by Sequent was to be able to scale to more than the default 8 processors (I believe the APIC ID is a 4 bit value -- placing an upper limit of 32 processors on Intel MP spec compliant MP implementations), which is where the SVR4/Solaris cost/benefit ratio breaks down because of the immense amount of bus activity needed to perform interprocessor synchronization through a global VM lock. The Sequent model fails because they are medium-granularity: in point of fact, the FS was not reentrant; this can be proven by starting multiple finds, which will run on different processors, and run seperately and sequentially to completion because of the non-reentrancy of the FS on a per-processor basis. This is utterly bogus (the 160% number from SVR4 should prove that). The Sequent model also fails because it does not allocate zones in terms of slabs. In terms of practical effect, we will have a global lock for the system, a non-cacheable sub-hierarchy for system-wide resources which can be allocated to a given processor (no contention unless two processors try to refill their pagepools at the same time, etc.), and a cacheable sub-hierarchy per processor. If a process references a resource owned by a processor other than the one it is on, it's no problem, unless it is an IPC area (which must be non-cacheable or support MESI, not MEI, updating in the MMU hardware). If, on the other hand, it tries to discard the resource, then the discard must either go through the processor that the resource was allocated from, or their must be a synchronixzation update to tell the owning processor that the reference has been discarded by another processor (unlikely, assuming a scheduler implementation for processor affinity). In any case, the page allocation map can preferentially be updated while the global mutex is held to fill the per processor page pool (or to empty it, if it hits the high-water mark), so a processor can know, on a given discard, who owns the page where the allocation exists. Obviously, since the allcoation is to the process (/kernel thread), only the valid own can discard it. What is mutexed is the allocation bitmap for the slab, and that can be done via messaging, to be run in the idle loop of the processor... processor A releasing an allocation for a process that was allocated for the process by processor B need not cause a synchronization event for any other processor in the system (this implies an IPC mechanism using non-cacheable pages, one page per processor per processor, and a third lock subhierarchy in a non-cached page, to be used when processor A and B are contending for the IPC area -- only in the idle: total 260k for 8 processors: 8 * 8 * 4k + 4k -- 1M for 16 processors, 4M for 32 processors). If we have to worry about more than that, we can establish communications clusters... would that we had someone beating down our door with 64 or more processor hardware. 8-). I think it is ultimately unreasonable to place a granularity limit and therefore a 4-8 processor limit on the architecture. I also think that any granularity limit inhernetly increases bus contention, and even with Active Server technology coming on line quickly, the limit in the end is still going to be I/O binding, not compute binding. Anything we can do to reduce bus contention *must* be a win. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Tue Jun 4 17:09:30 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA24352 for smp-outgoing; Tue, 4 Jun 1996 17:09:30 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA24346 for ; Tue, 4 Jun 1996 17:09:26 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA27752; Tue, 4 Jun 1996 17:03:57 -0700 From: Terry Lambert Message-Id: <199606050003.RAA27752@phaeton.artisoft.com> Subject: Re: Unix/NT synchronization model (was: SMP progress?) To: davidg@Root.COM Date: Tue, 4 Jun 1996 17:03:57 -0700 (MST) Cc: sef@kithrup.com, smp@freebsd.org In-Reply-To: <199606042324.QAA00541@Root.COM> from "David Greenman" at Jun 4, 96 04:24:35 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Okay, so that's an extremely short-ranged goal ;). But I don't expect true > >symmetric MP to be happening for quite some time yet -- there's just too > >much that would have to be changed. (Locks around nearly every structure > >reference in the kernel, for example.) > > What do you mean by "true symmetric MP"? The current stuff is "true SMP". > Just because it is coarse-grained, doesn't mean it isn't SMP. I was under the impression that the current code did not run the APIC's in virtual wire mode -- correct me if I'm wrong, since I haven't paid particular attention to that area in the last week or so; I've been flying all over. 8-(. That means that there is a preferred processor for taking interrupts, specifically the BP (boot processor) and that AP's (Application Processors) can't deal with them yet. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Tue Jun 4 17:20:07 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA24677 for smp-outgoing; Tue, 4 Jun 1996 17:20:07 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA24672 for ; Tue, 4 Jun 1996 17:20:05 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA27773; Tue, 4 Jun 1996 17:10:34 -0700 From: Terry Lambert Message-Id: <199606050010.RAA27773@phaeton.artisoft.com> Subject: Re: Unix/NT synchronization model (was: SMP progress?) To: davidg@Root.COM Date: Tue, 4 Jun 1996 17:10:34 -0700 (MST) Cc: michaelv@HeadCandy.com, sef@kithrup.com, smp@freebsd.org In-Reply-To: <199606042336.QAA00591@Root.COM> from "David Greenman" at Jun 4, 96 04:36:52 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >For example, if I were to go find an OSF/1 (Digital Unix) system and > >play around with it, would that be a good representation place to > >start? Or would someone say "Oh no! Don't look at Digital Unix -- > >it's SMP support really sucks!" :-) I'm just looking for peoples' > >ideas and opinions here -- not an over-riding edict. Tell me what > >your favorite Unix SMP system is... > > You may want to take a look at Mach's SMP locking and structure. It's not > exactly what we'll be doing in FreeBSD, but it's not a too-bad example. Of > course Mach is a microkernel design, but just overlook that while you're > looking at the SMP related stuff. :-) > Early SMP versions of just about every SMP Unix OS I know of started out > being a single lock and became fine-grained in subsequant versions (in many > cases before the code was officially released). Yes. The simplest method of increasing granularity is to tier the locks as global mutexes (not fix that yet), and then "push down" the locks through th trap code into the system call layer. At that point, you are free to add locks to structures accessed as a result of an interrupt or exception (the only two ways, other than the trap, to get into the kernel), and then you can multithread the whole damn thing, one subsystem at a time. You break the trap lock into inferior locks, one per subsystem (ie: VFS), and then break that lock further to push down a call at a time in the given subsystem. There is not a whole lot of global state that we have to worry about, other than entrancy counting so that a lock and a total can be set for getting everyone out of a given seperable module (ie: one processor wants to unload NFS, but nother one is using it, etc.). You can deal with per processor resources vs. system resources vs. system-but-per-processor-allocable resources to reduce bus overhead for interprocessor synchronization later. The "biggie" in that regard is, of course, VM, at a page granularity. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Tue Jun 4 17:20:46 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA24702 for smp-outgoing; Tue, 4 Jun 1996 17:20:46 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA24697; Tue, 4 Jun 1996 17:20:43 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA27796; Tue, 4 Jun 1996 17:16:09 -0700 From: Terry Lambert Message-Id: <199606050016.RAA27796@phaeton.artisoft.com> Subject: Re: Unix/NT synchronization model (was: SMP progress?) To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Tue, 4 Jun 1996 17:16:08 -0700 (MST) Cc: michaelv@HeadCandy.com, sef@kithrup.com, smp@freebsd.org In-Reply-To: <199606042353.QAA23687@freefall.freebsd.org> from "Justin T. Gibbs" at Jun 4, 96 04:53:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >But maybe I'm not stating myself clearly. :-) What I'm really after is > >recommendations on where I should look if I want to see how another > >SMP Unix implements synchronization controls. I just want to find out > >how other people have implemented it. All I know is Windows NT (SMP, > >not in general, of course), and I want to see a contrasting > >implementation. > > Aren't you really asking about thread and process syncronization? This is > an issue regardless of whether the system is SMP. > > I've also only dealt with the NT implementations of critical sections and > mutexes, and unlike the rest of the win32 API, it seems they did a fairly > good job of it (although there are some additional scheduling controls I > wish were provided). Actually, if you look, their semaphoring mechanism allows a particular thread to reenter the kernel to service an async event. Basically, any blocked thread is "fair game" for this. If you expect to run service processes in the kernel (ie: a UFS updated, etc.), then you will need to build a counting semaphore on top of the thread semaphores for reentrancy locking for critical sections. I've been bit in the butt by this under both NT and Windows 95 (which has a similar interface for Ring0 applications -- VxD's). 8-(. The Solaris/SVR4 model is OK -- has anyone seen the Unisys 6000 series SVR4/MP based on the pre-Solaris merge 4.0.2 SVR4 release? Their FS locking in particular, is *very*, *very* well written. It took me about three months to get an FS up in the Solaris multithreaded kernel, where I allowed reentrancy, but it only took me about two weeks on the SVR4/MP box from Unisys. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Tue Jun 4 21:08:45 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA22902 for smp-outgoing; Tue, 4 Jun 1996 21:08:45 -0700 (PDT) Received: from critter.tfs.com (critter.cdrom.com [204.216.27.38]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA22886; Tue, 4 Jun 1996 21:08:39 -0700 (PDT) Received: from critter.tfs.com (localhost [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id QAA02218; Tue, 4 Jun 1996 16:45:49 -0700 (PDT) To: Terry Lambert cc: sef@kithrup.com, smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) In-reply-to: Your message of "Tue, 04 Jun 1996 17:01:14 PDT." <199606050001.RAA27740@phaeton.artisoft.com> Date: Tue, 04 Jun 1996 16:45:43 -0700 Message-ID: <2215.833931943@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry started: >Actually, I disagree with this. I think that the higher grain the >parallelism, the better the ... Terry, feel free. We will consider you patches when we see them. Poul-Henning -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Tue Jun 4 22:11:55 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA29582 for smp-outgoing; Tue, 4 Jun 1996 22:11:55 -0700 (PDT) Received: from MindBender.HeadCandy.com (root@[199.238.225.168]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA29570; Tue, 4 Jun 1996 22:11:49 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.HeadCandy.com (8.7.5/8.6.9) with SMTP id WAA25213; Tue, 4 Jun 1996 22:11:37 -0700 (PDT) Message-Id: <199606050511.WAA25213@MindBender.HeadCandy.com> X-Authentication-Warning: MindBender.HeadCandy.com: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: "Justin T. Gibbs" cc: Sean Eric Fagan , smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) In-reply-to: Your message of Tue, 04 Jun 96 16:53:02 -0700. <199606042353.QAA23687@freefall.freebsd.org> Date: Tue, 04 Jun 1996 22:11:36 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>But maybe I'm not stating myself clearly. :-) What I'm really after is >>recommendations on where I should look if I want to see how another >>SMP Unix implements synchronization controls. I just want to find out >>how other people have implemented it. All I know is Windows NT (SMP, >>not in general, of course), and I want to see a contrasting >>implementation. >Aren't you really asking about thread and process syncronization? This is >an issue regardless of whether the system is SMP. Well, yes, they're not strictly related. But, I have yet to see a non-SMP Unix where they cared about such things. So, in reality (in my mind, anyway -- whether that's reality is subject for a different debate... ;-), a decent SMP Unix precedes good process/thread synchronization facilities, and an SMP Unix with lousy process/thread synchronization facilities would probably suck at being SMP. (Does that make sense?) Anyway, the way I see it you need *some* kind of synchronization to get the kernel running MP. What would be the most beneficial synchronization primatives to get the kernel running? I don't know -- I think it's pretty obvious my kernel MP experience is about this big: -><-. I can think abstractly about what it would take to make such a thing -- I'm just struggling a little on the actual implementation. Terry posted a very interesting little tome today on this subject. Now, if I can get him to boil it down to pictures and words I can understand, I'll be in really good shape. :-) Anyway, from what he said, it sounds like I have the right concepts in place in my head. I just need to work on filling them out. I'll go read some books and some code instead of bugging this list with a whole bunch more questions, though. :-) >I've also only dealt with the NT implementations of critical sections and >mutexes, and unlike the rest of the win32 API, it seems they did a fairly >good job of it (although there are some additional scheduling controls I >wish were provided). Yes, in general I think the NT kernel has a lot of cool things going for it. It's all the gunky Windows-based API layers above it that make NT so bloated. I wouldn't mind seeing userland process/thread synchronization facilities like those in NT. Which is why I want to see how it's done in a modern Unix. Maybe there's a "better" way. Or, at least a more "standard" way. It would be kinda dumb to put together a bunch of sync stuff that looks like NT, nice as it might be, when everything else written for an MP or threaded Unix works totally different. I don't want to be locked into an NT paradigm. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@HeadCandy.com --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... Roll your own Internet access -- Seattle People's Internet cooperative. If you're in the Seattle area, ask me how. ----------------------------------------------------------------------------- From owner-freebsd-smp Tue Jun 4 22:21:36 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA02186 for smp-outgoing; Tue, 4 Jun 1996 22:21:36 -0700 (PDT) Received: from MindBender.HeadCandy.com (root@[199.238.225.168]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA02155 for ; Tue, 4 Jun 1996 22:21:22 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.HeadCandy.com (8.7.5/8.6.9) with SMTP id WAA25284; Tue, 4 Jun 1996 22:19:47 -0700 (PDT) Message-Id: <199606050519.WAA25284@MindBender.HeadCandy.com> X-Authentication-Warning: MindBender.HeadCandy.com: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) In-reply-to: Your message of Tue, 04 Jun 96 17:10:34 -0700. <199606050010.RAA27773@phaeton.artisoft.com> Date: Tue, 04 Jun 1996 22:19:45 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Early SMP versions of just about every SMP Unix OS I know of started out >> being a single lock and became fine-grained in subsequant versions (in many >> cases before the code was officially released). >Yes. The simplest method of increasing granularity is to tier the >locks as global mutexes (not fix that yet), and then "push down" the >locks through th trap code into the system call layer. What exactly do you mean by "push down the locks through the trap code"? >At that point, you are free to add locks to structures accessed as a >result of an interrupt or exception (the only two ways, other than the >trap, to get into the kernel), and then you can multithread the whole >damn thing, one subsystem at a time. Kind of how I had envisioned it... >You break the trap lock into inferior locks, one per subsystem (ie: VFS), >and then break that lock further to push down a call at a time in the >given subsystem. What exactly do you mean by breaking the lock down? Are you saying to have a general lock cover a broad range of kernel access, then make a more specific lock for a subset of that range and remove that subset from the broader lock? ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@HeadCandy.com --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... Roll your own Internet access -- Seattle People's Internet cooperative. If you're in the Seattle area, ask me how. ----------------------------------------------------------------------------- From owner-freebsd-smp Wed Jun 5 02:53:31 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA06785 for smp-outgoing; Wed, 5 Jun 1996 02:53:31 -0700 (PDT) Received: from perki0.connect.com.au (perki0.connect.com.au [192.189.54.85]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA06773 for ; Wed, 5 Jun 1996 02:53:26 -0700 (PDT) Received: (from uucp@localhost) by perki0.connect.com.au id TAA15075 (8.7.5/IDA-1.6); Wed, 5 Jun 1996 19:51:02 +1000 (EST) >Received: from localhost (giles@localhost [127.0.0.1]) by nemeton.com.au (8.6.12/8.6.9) with SMTP id TAA03549; Wed, 5 Jun 1996 19:46:38 +1000 Message-Id: <199606050946.TAA03549@nemeton.com.au> To: "Michael L. VanLoon -- HeadCandy.com" cc: smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) In-reply-to: <199606042316.QAA24168@MindBender.HeadCandy.com> Date: Wed, 05 Jun 1996 19:46:36 +1000 From: Giles Lean Content-Type: text Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 04 Jun 1996 16:16:46 -0700 "Michael L. VanLoon -- HeadCandy.com" wrote: I'd look at "UNIX Systems for Modern Architetures" by Curt Schimmel (Addison Wesley, ISBN 0-201-6338-8) and possibly "UNIX Internals: the New Frontiers" by Uresh Vahalia (Prentice Hall, ISBN 0-13-101908-2). Both of these books are excellent, but fair warning: I'm not a kernel hacker! Giles From owner-freebsd-smp Wed Jun 5 10:20:15 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA16864 for smp-outgoing; Wed, 5 Jun 1996 10:20:15 -0700 (PDT) Received: (from jmb@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA16854; Wed, 5 Jun 1996 10:20:12 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199606051720.KAA16854@freefall.freebsd.org> Subject: Re: Unix/NT synchronization model (was: SMP progress?) To: michaelv@HeadCandy.com (Michael L. VanLoon -- HeadCandy.com) Date: Wed, 5 Jun 1996 10:20:12 -0700 (PDT) Cc: gibbs@freefall.freebsd.org, sef@kithrup.com, smp@freebsd.org In-Reply-To: <199606050511.WAA25213@MindBender.HeadCandy.com> from "Michael L. VanLoon -- HeadCandy.com" at Jun 4, 96 10:11:36 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Michael L. VanLoon -- HeadCandy.com wrote: > Which is why I want to see how it's done in a modern Unix. Maybe > there's a "better" way. Or, at least a more "standard" way. It would > be kinda dumb to put together a bunch of sync stuff that looks like > NT, nice as it might be, when everything else written for an MP or > threaded Unix works totally different. I don't want to be locked into > an NT paradigm. SunExpert magazine did a four article series on threads beginning with the feb '96 issue. the last article in the series (may '96) compares pthreads with solaris threads. its all api level stuff jmb -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ From owner-freebsd-smp Wed Jun 5 11:06:13 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA20756 for smp-outgoing; Wed, 5 Jun 1996 11:06:13 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA20751 for ; Wed, 5 Jun 1996 11:06:11 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA29231; Wed, 5 Jun 1996 11:00:39 -0700 From: Terry Lambert Message-Id: <199606051800.LAA29231@phaeton.artisoft.com> Subject: Re: Unix/NT synchronization model (was: SMP progress?) To: michaelv@HeadCandy.com (Michael L. VanLoon -- HeadCandy.com) Date: Wed, 5 Jun 1996 11:00:39 -0700 (MST) Cc: terry@lambert.org, smp@freebsd.org In-Reply-To: <199606050519.WAA25284@MindBender.HeadCandy.com> from "Michael L. VanLoon -- HeadCandy.com" at Jun 4, 96 10:19:45 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> Early SMP versions of just about every SMP Unix OS I know of started out > >> being a single lock and became fine-grained in subsequant versions (in many > >> cases before the code was officially released). > > >Yes. The simplest method of increasing granularity is to tier the > >locks as global mutexes (not fix that yet), and then "push down" the > >locks through th trap code into the system call layer. > > What exactly do you mean by "push down the locks through the trap > code"? > > >At that point, you are free to add locks to structures accessed as a > >result of an interrupt or exception (the only two ways, other than the > >trap, to get into the kernel), and then you can multithread the whole > >damn thing, one subsystem at a time. > > Kind of how I had envisioned it... > > >You break the trap lock into inferior locks, one per subsystem (ie: VFS), > >and then break that lock further to push down a call at a time in the > >given subsystem. > > What exactly do you mean by breaking the lock down? Are you saying to > have a general lock cover a broad range of kernel access, then make a > more specific lock for a subset of that range and remove that subset > from the broader lock? Yes. The lock structure needs to be a hierarchy. Intention modes need to be implemented so that the hierarchy is not exclusive access all the way to the root lock (the kernel entry mutex). The hierarchy is necessary for deadlock avoidance, which is on the order of twice as efficient as deadlock detection, since you do not need to unwind state to recover from a conflict. 1) Start with a kernel entrancy lock in the exception, interrupt, and trap code. 2) Make the trap code reentrant. 3) Move the kernel entrancy locks from the trap code itself into the trap call targets (sysent[] functions). 4) Fan out the locking as a hierarchy so that sysent[] functions are classed by subsystem: VM, FS, Process, etc. 5) Convert the top level lock in the hierarchy to an IX lock so that synchronization is done on a subsystem basis instead of a trap entry basis. 6) Make one subsystem reentrant by taking the subsystem lock under the entrancy lock hierarchy, and fanning it out ona per-resource basis, locking common resources between calls in the subsystem. 7) Convert the per subsystem lock that is the parent for the common resource locks to an IX lock so that synchronization is done on a resource basis instead of a subsystem basis. 8) Start in on the next subsystem. Where possible, all new code should be single-entry, single-exit, so the lock state is clear, and is seperate from a direct understanding of the function of the code. Otherwise, it will end up being one or two people doing a massive code integration instead of a bunch of people doing little code integrations... you can't break the problem up into units if you have to have a holistic implementation (ie: all the code affected at once). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Wed Jun 5 11:15:36 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA21531 for smp-outgoing; Wed, 5 Jun 1996 11:15:36 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA21525; Wed, 5 Jun 1996 11:15:34 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA29266; Wed, 5 Jun 1996 11:10:43 -0700 From: Terry Lambert Message-Id: <199606051810.LAA29266@phaeton.artisoft.com> Subject: Re: Unix/NT synchronization model (was: SMP progress?) To: jmb@freefall.freebsd.org (Jonathan M. Bresler) Date: Wed, 5 Jun 1996 11:10:43 -0700 (MST) Cc: michaelv@HeadCandy.com, gibbs@freefall.freebsd.org, sef@kithrup.com, smp@freebsd.org In-Reply-To: <199606051720.KAA16854@freefall.freebsd.org> from "Jonathan M. Bresler" at Jun 5, 96 10:20:12 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Michael L. VanLoon -- HeadCandy.com wrote: > > Which is why I want to see how it's done in a modern Unix. Maybe > > there's a "better" way. Or, at least a more "standard" way. It would > > be kinda dumb to put together a bunch of sync stuff that looks like > > NT, nice as it might be, when everything else written for an MP or > > threaded Unix works totally different. I don't want to be locked into > > an NT paradigm. > > SunExpert magazine did a four article series on threads beginning > with the feb '96 issue. the last article in the series (may '96) > compares pthreads with solaris threads. > > its all api level stuff I just had a huge discussion with a Sun engineer on threading internals, and specifically on whether or not it should be possible to block a kernel thread as a result of a system call, or only a user thread (my position was that once the kernel gives me a quantum, it's *my* damn quantum). Probably the best reference for synchronization primitives in an SMP and/or kernel multithreading environemnt is in "UNIX for modern architectures", and the best explanation for the competitive trade-offs and implementation details is "UNIX Internals: The New Frontiers". There is supposedly another version of "The Magic Garden Explained" coming out, but given the lack of depth on what I considered some fundamental issues (namely, the DNLC) in the previous version of the book, I don't have a lot of hope there. There are also some interesting papers on threading in both kernel and user space at ftp.sage.usenix.org, the Usenix paper archive site. The University of Washington has also got a couple of interesting papers, though mostly dealing with user space threading (the SunOS 4.x LWP code came out of a U of W project on "SPARC Register windows and User Space Threading"). I suspect that the first order of business would be to turnstile the mutex code to get rid of the "thundering herd" problem that it currently has for more than one AP. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Wed Jun 5 11:29:47 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA22427 for smp-outgoing; Wed, 5 Jun 1996 11:29:47 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA22421; Wed, 5 Jun 1996 11:29:44 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA29307; Wed, 5 Jun 1996 11:24:53 -0700 From: Terry Lambert Message-Id: <199606051824.LAA29307@phaeton.artisoft.com> Subject: Re: Unix/NT synchronization model (was: SMP progress?) To: phk@freebsd.org (Poul-Henning Kamp) Date: Wed, 5 Jun 1996 11:24:53 -0700 (MST) Cc: terry@lambert.org, sef@kithrup.com, smp@freebsd.org In-Reply-To: <2215.833931943@critter.tfs.com> from "Poul-Henning Kamp" at Jun 4, 96 04:45:43 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Actually, I disagree with this. I think that the higher grain the > >parallelism, the better the ... > > Terry, feel free. We will consider you patches when we see them. After Jeffrey Hsu has worked around the problem with the Lite2 code integration (I am not convinced that it isn't a side effect of the recent VM changes, which have shown up a lot of broken assumptions in the CSRG code), and the Lite2 code is brought into the -current tree, I will work on Lite2-ing my FS patches. If you will remember, my FS patches addressed issues of fine grain parallelism, starting in June of 1995 (ie: it has been more than a year since you first saw the patches you are requesting). In point of fact, I have already prepared all of vfs_syscalls.c for the lock pushdown from the trap code, as described in my previous post, by making them single-entry/single-exit. I really don't see why the patches need to be all-or-nothing for you to even consider them in the first place... all that requirement does is make eventual integration more difficult (and thus unlikely). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Wed Jun 5 11:37:09 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA22798 for smp-outgoing; Wed, 5 Jun 1996 11:37:09 -0700 (PDT) Received: from critter2.tfs.com ([140.145.16.108]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA22793; Wed, 5 Jun 1996 11:37:07 -0700 (PDT) Received: from critter2.tfs.com (localhost [127.0.0.1]) by critter2.tfs.com (8.7.5/8.7.3) with ESMTP id LAA01041; Wed, 5 Jun 1996 11:36:33 -0700 (PDT) To: Terry Lambert cc: sef@kithrup.com, smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) In-reply-to: Your message of "Wed, 05 Jun 1996 11:24:53 PDT." <199606051824.LAA29307@phaeton.artisoft.com> Date: Wed, 05 Jun 1996 11:36:31 -0700 Message-ID: <1039.833999791@critter2.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199606051824.LAA29307@phaeton.artisoft.com>, Terry Lambert writes: >> >Actually, I disagree with this. I think that the higher grain the >> >parallelism, the better the ... >> >> Terry, feel free. We will consider you patches when we see them. > >After Jeffrey Hsu has worked around the problem with the Lite2 >code integration (I am not convinced that it isn't a side effect >of the recent VM changes, which have shown up a lot of broken >assumptions in the CSRG code), and the Lite2 code is brought into >the -current tree, I will work on Lite2-ing my FS patches. > >If you will remember, my FS patches addressed issues of fine grain >parallelism, starting in June of 1995 (ie: it has been more than >a year since you first saw the patches you are requesting). But I still havn't been able to compile them, and I stil havn't been able to get them without the "attached strings" of other potentially unwanted patches. :-) >In point of fact, I have already prepared all of vfs_syscalls.c for >the lock pushdown from the trap code, as described in my previous >post, by making them single-entry/single-exit. I really don't see >why the patches need to be all-or-nothing for you to even consider >them in the first place... all that requirement does is make >eventual integration more difficult (and thus unlikely). my words exactly. Except >I< think that >you< should do the work of keep the issues separate rather than me trying to separate them. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Wed Jun 5 12:03:38 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA24136 for smp-outgoing; Wed, 5 Jun 1996 12:03:38 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA24129; Wed, 5 Jun 1996 12:03:35 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA29430; Wed, 5 Jun 1996 11:58:44 -0700 From: Terry Lambert Message-Id: <199606051858.LAA29430@phaeton.artisoft.com> Subject: Re: Unix/NT synchronization model (was: SMP progress?) To: phk@freebsd.org (Poul-Henning Kamp) Date: Wed, 5 Jun 1996 11:58:44 -0700 (MST) Cc: terry@lambert.org, sef@kithrup.com, smp@freebsd.org In-Reply-To: <1039.833999791@critter2.tfs.com> from "Poul-Henning Kamp" at Jun 5, 96 11:36:31 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >In point of fact, I have already prepared all of vfs_syscalls.c for > >the lock pushdown from the trap code, as described in my previous > >post, by making them single-entry/single-exit. I really don't see > >why the patches need to be all-or-nothing for you to even consider > >them in the first place... all that requirement does is make > >eventual integration more difficult (and thus unlikely). > > my words exactly. Except >I< think that >you< should do the work > of keep the issues separate rather than me trying to separate them. With respect, this is much more difficult for those of us who must do our changes locally and use SUP or CTM to keep up to date. Each time I pull an updated tree from my local mirror of the CVS tree, I must re-merge and re-integrate all of my patches. What you are asking me to do is to do this for multiple trees (which I'm perfectly willing to do for logically seperate structures). The problem arises for me when, for instance, I want to do work on something that requires an agregate of multiple patch sets to allow me to work on yet another thing. Because my code is locally not under source code control because of the way the mirroring operates, I have no way of producing a local source tree with an agregated set of local patches. Short of manually agregating them into a single tree, and then we have the problem you describe, where my patches aren't acceptable to you for seperate consideration. My motivation in doing these sub-patches is to get an agregate that I can use locally. It does me no good to lay out 8 pylons if I can't use them in combination to build an overpass. My motivation is what I build on top of the agregated patches, not the patches as individual small-scope changes. --- This is really a tools problem. We need some way of integrating CVS trees so that I can locally set a branch tag for each one of the various small-scope patches, yet still integrate updates to the untagged branch as incremental updates -- ie: as local checkin on the unbranched portion of the tree. Unfortunately, short of rewriting CVS, I don't see an easy way of achiveing an agregate (my goal) while maintaining seperable small-scope patches (your goal). I would be more than happy if you could suggest *anything* to get around this conflict: it would most certainly result in me providing the small-scope patches you want, without interfering with my ability to do my own real work. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Wed Jun 5 12:10:28 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA24429 for smp-outgoing; Wed, 5 Jun 1996 12:10:28 -0700 (PDT) Received: from critter2.tfs.com ([140.145.16.108]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA24423; Wed, 5 Jun 1996 12:10:26 -0700 (PDT) Received: from critter2.tfs.com (localhost [127.0.0.1]) by critter2.tfs.com (8.7.5/8.7.3) with ESMTP id MAA01858; Wed, 5 Jun 1996 12:09:54 -0700 (PDT) To: Terry Lambert cc: sef@kithrup.com, smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) In-reply-to: Your message of "Wed, 05 Jun 1996 11:58:44 PDT." <199606051858.LAA29430@phaeton.artisoft.com> Date: Wed, 05 Jun 1996 12:09:52 -0700 Message-ID: <1856.834001792@critter2.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199606051858.LAA29430@phaeton.artisoft.com>, Terry Lambert writes: >> >In point of fact, I have already prepared all of vfs_syscalls.c for >> >the lock pushdown from the trap code, as described in my previous >> >post, by making them single-entry/single-exit. I really don't see >> >why the patches need to be all-or-nothing for you to even consider >> >them in the first place... all that requirement does is make >> >eventual integration more difficult (and thus unlikely). >> >> my words exactly. Except >I< think that >you< should do the work >> of keep the issues separate rather than me trying to separate them. > >With respect, this is much more difficult for those of us who >must do our changes locally and use SUP or CTM to keep up to >date. Hey buddy, how do you think I work ???? >Each time I pull an updated tree from my local mirror of the CVS >tree, I must re-merge and re-integrate all of my patches. join the club. :-( -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Wed Jun 5 13:19:55 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA29672 for smp-outgoing; Wed, 5 Jun 1996 13:19:55 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA29664; Wed, 5 Jun 1996 13:19:52 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA29562; Wed, 5 Jun 1996 13:14:59 -0700 From: Terry Lambert Message-Id: <199606052014.NAA29562@phaeton.artisoft.com> Subject: Re: Unix/NT synchronization model (was: SMP progress?) To: phk@freebsd.org (Poul-Henning Kamp) Date: Wed, 5 Jun 1996 13:14:59 -0700 (MST) Cc: terry@lambert.org, sef@kithrup.com, smp@freebsd.org In-Reply-To: <1856.834001792@critter2.tfs.com> from "Poul-Henning Kamp" at Jun 5, 96 12:09:52 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >With respect, this is much more difficult for those of us who > >must do our changes locally and use SUP or CTM to keep up to > >date. > > Hey buddy, how do you think I work ???? I don't know; I just assumed that, like some of the other core team members, you put a branch tag on the real CVS tree and communicated changes between working groups that way. I remember a big discussion on CVS tag assignment on the -current list for using the CVS tree to communicate between people working on the same set of not-ready-for-prime-time code. > >Each time I pull an updated tree from my local mirror of the CVS > >tree, I must re-merge and re-integrate all of my patches. > > join the club. :-( And you don't find this intolerable when you get to 50,000 lines of patches in 4 different sub-areas so that you can agregate them and work on what you want to work on instead of eternally reintegrating the same sub-patches over-and-over-and-over...??? I got to the point, while I was working at Novell, that I spent all of my time integrating my patches and none of my time doing the work that the patches were supposed to support. It was worth leaving Novell and rewriting everything from scratch (to avoid "contamination") just to get to do real coding once again. It sucks out to have the tools put me back in the same position a year and a half after my escape. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Wed Jun 5 14:09:50 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA04948 for smp-outgoing; Wed, 5 Jun 1996 14:09:50 -0700 (PDT) Received: from critter.tfs.com ([140.145.16.108]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA04928; Wed, 5 Jun 1996 14:09:39 -0700 (PDT) Received: from critter.tfs.com (localhost [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id OAA00303; Wed, 5 Jun 1996 14:09:06 -0700 (PDT) To: Terry Lambert cc: sef@kithrup.com, smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) In-reply-to: Your message of "Wed, 05 Jun 1996 13:14:59 PDT." <199606052014.NAA29562@phaeton.artisoft.com> Date: Wed, 05 Jun 1996 14:09:06 -0700 Message-ID: <301.834008946@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199606052014.NAA29562@phaeton.artisoft.com>, Terry Lambert writes: >> >With respect, this is much more difficult for those of us who >> >must do our changes locally and use SUP or CTM to keep up to >> >date. >> >> Hey buddy, how do you think I work ???? > >I don't know; I just assumed that, like some of the other core >team members, you put a branch tag on the real CVS tree and You have as much access to the "real CVS tree" as I have. No we don't do branch tags for development. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Thu Jun 6 01:38:17 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA10938 for smp-outgoing; Thu, 6 Jun 1996 01:38:17 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA10932; Thu, 6 Jun 1996 01:38:14 -0700 (PDT) Received: from epprod.elsevier.co.uk (epprod.elsevier.co.uk [193.131.222.35]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id BAA19581 ; Thu, 6 Jun 1996 01:34:23 -0700 Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by epprod.elsevier.co.uk (8.6.13/8.6.12) with ESMTP id JAA05476; Thu, 6 Jun 1996 09:31:05 +0100 Received: from tees by snowdon with SMTP (PP); Thu, 6 Jun 1996 09:31:13 +0100 Received: (from dpr@localhost) by tees (SMI-8.6/8.6.12) id JAA24251; Thu, 6 Jun 1996 09:30:53 +0100 Date: Thu, 6 Jun 1996 09:30:53 +0100 Message-Id: <199606060830.JAA24251@tees> To: Poul-Henning Kamp Cc: Terry Lambert , sef@kithrup.com, smp@freebsd.org Subject: Re: Unix/NT synchronization model (was: SMP progress?) In-Reply-To: <1856.834001792@critter2.tfs.com> References: <199606051858.LAA29430@phaeton.artisoft.com> <1856.834001792@critter2.tfs.com> Reply-To: p.richards@elsevier.co.uk From: Paul Richards X-Attribution: Paul X-Mailer: GNU Emacs [19.30.1], RMAIL, Mailcrypt [3.3] Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> "Poul-Henning" == Poul-Henning Kamp writes: Poul-Henning> In message <199606051858.LAA29430@phaeton.artisoft.com>, >> Each time I pull an updated tree from my local mirror of the CVS >> tree, I must re-merge and re-integrate all of my patches. Poul-Henning> join the club. :-( Well, a cludge way to do it is to not ctm the cvs tree but just the source tree and then maintain your own cvs tree with the FreeBSD sources on a vendor branch. If you want to have FreeBSD's cvs tree as well then stick it somewhere else. The ctm patches to src then get applied to a vendor branch of *your* cvs tree. I've never tried this but I've been thinking about it a bit.