From owner-freebsd-smp Tue Nov 16 11:39:49 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mail.kpnqwest.ch (mail.eunet.ch [146.228.10.7]) by hub.freebsd.org (Postfix) with ESMTP id DCA0D15363 for ; Tue, 16 Nov 1999 11:39:43 -0800 (PST) (envelope-from fjaccard@webshuttle.ch) Received: from wwwsw.webshuttle.ch (www.webshuttle.ch [146.228.6.1]) by mail.kpnqwest.ch (8.9.3/1.34) via ESMTP id TAA27113 for ; Tue, 16 Nov 1999 19:39:41 GMT env-from (fjaccard@webshuttle.ch) Received: from sicel-3-213 (dyna-ls-46.dial.eunet.ch [193.72.6.206]) by wwwsw.webshuttle.ch (8.9.3/8.8.2) with ESMTP id UAA01987 for ; Tue, 16 Nov 1999 20:39:34 +0100 (MET) Message-Id: <4.2.2.19991116203648.00c1ae40@mail.vtx.ch> X-Sender: fjaccard@pop.webshuttle.ch X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 16 Nov 1999 20:38:15 +0100 To: freebsd-smp@FreeBSD.ORG From: Francois E Jaccard Subject: PIII stepping 2 and 3 as SMP? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I have 2 PIII 500, one is stepping 2 and the other stepping 3. Can I use them on an Asus P2B-D mobo under FreeBSD 4.0-current? Thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Nov 16 12: 6:57 1999 Delivered-To: freebsd-smp@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id A50DE15281; Tue, 16 Nov 1999 12:06:49 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id VAA26898; Tue, 16 Nov 1999 21:06:43 +0100 (CET) (envelope-from phk@critter.freebsd.dk) Date: Tue, 16 Nov 1999 21:06:42 +0100 Message-ID: <26892.942782802.1@critter.freebsd.dk> From: Poul-Henning Kamp Subject: Re: the ps/cmdline caching MIME-Version: 1.0 Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa" Content-Description: Blind Carbon Copy Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ------- =_aaaaaaaaaa Content-Type: message/rfc822 Content-Description: Original Message To: core@freebsd.org Subject: Re: the ps/cmdline caching In-reply-to: Your message of "Tue, 16 Nov 1999 11:37:40 MST." <199911161837.LAA00345@caspian.plutotech.com> Date: Tue, 16 Nov 1999 21:06:42 +0100 Message-ID: <26892.942782802@critter.freebsd.dk> From: Poul-Henning Kamp MIME-Version: 1.0 In message <199911161837.LAA00345@caspian.plutotech.com>, "Justin T. Gibbs" wri tes: >I must have missed a thread somewhere. Can I get a reference to what >this problem is? Run this on a SMP box and it will die in seconds: i=0 while [ $i -lt 200 ] do i=`expr $i + 1` ( while true ; do ps xao pid,command > /dev/null 2>&1 ; done ) & done The problem is where ps using /proc/%pid/mem grovels around in the other process address room to get hold of argv. This gets particular nasty when we have multiple copies of ps(1) running on a SMP box: First CPU: running process 100 which is a "ps -ax" currently trying to get the argument list from process 101 Second CPU: running process 101 which is a "ps -ax" currently trying to get the argument list from process 101 (or 100 for that matter). The code in procfs_mem.c has significant problems in this scenario, and rather than try to hunt them down, something we should eventually do my solution is to hang a copy of of the arg list from struct proc and use a sysctl in the kern.proc family to access it. My implementation has a sysctl variable which sets an upper limit on how many bytes we use per process for this. If this limit is exceeded, we default to the current reality, obviously the limit can be set to zero as well. For anyone wanting to work on procfs_mem, setting the sysctl to zero will revert to current behaviour so that bug is not obscured. The arguments are stored in a separate structure which is shared across fork and replaced in exec, so the overhead in struct proc itself is only a pointer, and for daemons which fork a lot of children only one copy of the arguments are stored, until they set their own with setproctitle() that is. The side effects of this change are many and varied: Plus side: 1. ps(1) runs much faster and uses far fewer resources. 2. ps(1) don't need a /proc anymore. Particular nice for chroot and jail. 3. We get access to the full command line in kernel debuggers. 4. (untested/unimplemented) /bin/ps doesn't need to be setgid kmem anymore. 5. On the long run we use less memory because we don't need to i allocate a vnode and inode for /proc/%pid/mem. (This is not implemented yet, we need to figure out how much ps(1) should use libkvm and fix it accordingly). On the minus side: 1. Memory usage, if all your process have very long commandlines. (You can limit this with the sysctl.) 2. A process which writes to argv[0] rather than use setproctitle() doesn't have the desired effect. (Setting the sysctl to zero solves this problem as well.) 3. If you never run ps(1) there is a epsilon sized overhead in exec(2). (You can make that a epsilon-squared sized overhead by setting the sysctl to zero.) So expect to hear a happy Paul Saab sing our praise once again and expect to see my commit to -current in a few moments. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! ------- =_aaaaaaaaaa-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Nov 17 10:48:24 1999 Delivered-To: freebsd-smp@freebsd.org Received: from houston.matchlogic.com (houston.matchlogic.com [205.216.147.127]) by hub.freebsd.org (Postfix) with ESMTP id 71E661533B for ; Wed, 17 Nov 1999 10:48:15 -0800 (PST) (envelope-from crandall@matchlogic.com) Received: by houston.matchlogic.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Nov 1999 11:48:14 -0700 Message-ID: <64003B21ECCAD11185C500805F31EC0304621F00@houston.matchlogic.com> From: Charles Randall To: freebsd-smp@freebsd.org Subject: Big Giant Lock progress? Date: Wed, 17 Nov 1999 11:48:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Where can I find an update on the progress of slowly chipping away at the BGL? I saw Alfred's "SMP Infoletter #1". Is that the latest info? -Charles To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Nov 17 10:51:54 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id BFB3714F68 for ; Wed, 17 Nov 1999 10:51:52 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA65437; Wed, 17 Nov 1999 10:51:48 -0800 (PST) (envelope-from dillon) Date: Wed, 17 Nov 1999 10:51:48 -0800 (PST) From: Matthew Dillon Message-Id: <199911171851.KAA65437@apollo.backplane.com> To: Charles Randall Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Big Giant Lock progress? References: <64003B21ECCAD11185C500805F31EC0304621F00@houston.matchlogic.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :Where can I find an update on the progress of slowly chipping away at the :BGL? : :I saw Alfred's "SMP Infoletter #1". Is that the latest info? : :-Charles Alfred got caught up in real life work so it's been on hold for a while. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Nov 17 19:35:37 1999 Delivered-To: freebsd-smp@freebsd.org Received: from xena.cs.waikato.ac.nz (xena.cs.waikato.ac.nz [130.217.241.20]) by hub.freebsd.org (Postfix) with ESMTP id 772E914BEE for ; Wed, 17 Nov 1999 19:35:23 -0800 (PST) (envelope-from joerg@lucy.cs.waikato.ac.nz) Received: from lucy.cs.waikato.ac.nz (joerg@lucy.cs.waikato.ac.nz [130.217.241.12]) by xena.cs.waikato.ac.nz (8.9.3/8.9.3) with ESMTP id QAA14996; Thu, 18 Nov 1999 16:35:18 +1300 (NZDT) Received: (from joerg@localhost) by lucy.cs.waikato.ac.nz (8.9.3/8.9.0) id QAA14018; Thu, 18 Nov 1999 16:35:16 +1300 (NZDT) Date: Wed, 17 Nov 1999 18:24:16 +1300 From: Joerg Micheel To: freebsd-smp@freebsd.org Cc: joerg@cs.waikato.ac.nz Subject: Seeking recommendations/stories for big servers Message-ID: <19991118163516.D10829@cs.waikato.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: SCMS, The University of Waikato, Hamilton, New Zealand Project: WAND - Waikato Applied Network Dynamics, DAG Operating-System: ... drained by Solaris 7 SPARC Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We are planning to configure a big multiprocessor system (4/8 Xeon), with 0.5-2.0GB of memory and a huge SCSI subsystem (1/2 to 3/4 of a terabyte). The system will be used to store and process large Internet trace files, quite likely in gzip'ed form. There will be massive sequential access, many files will be readonly. I'd be interested to hear some experience/stories from people running such systems. I need to make a choice among the big PC manufacturers (Dell, Compaq, you name it). I'm interested in running vinum rather than a commercial RAID product (if any form of RAID is required at all). I'm also interested about network-fanout stories. We may NFS-mount the server and have a 100MBit Ethernet box behind it for access from a farm of PCs. Thanks for your time! Joerg Micheel -- Joerg B. Micheel Email: Waikato Applied Network Dynamics Phone: +64 7 8384794 The University of Waikato, SCMS Fax: +64 7 8384155 Private Bag 3105 Pager: +64 868 38222 Hamilton, New Zealand Plan: TINE and the DAG's To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Nov 18 0:19:12 1999 Delivered-To: freebsd-smp@freebsd.org Received: from houston.matchlogic.com (houston.matchlogic.com [205.216.147.127]) by hub.freebsd.org (Postfix) with ESMTP id E04441540D for ; Thu, 18 Nov 1999 00:18:59 -0800 (PST) (envelope-from crandall@matchlogic.com) Received: by houston.matchlogic.com with Internet Mail Service (5.5.2650.21) id ; Thu, 18 Nov 1999 01:18:59 -0700 Message-ID: <64003B21ECCAD11185C500805F31EC0304621F4F@houston.matchlogic.com> From: Charles Randall To: freebsd-smp@FreeBSD.ORG Subject: RE: Big Giant Lock progress? Date: Thu, 18 Nov 1999 01:18:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org From: Matthew Dillon [mailto:dillon@apollo.backplane.com] > Alfred got caught up in real life work so it's been on hold for a while. Has anyone profiled an SMP kernel in a standard role (Web server, NFS server, development machine, etc) and compared the points of BGL contention with the ease (or difficulty) of more fine-grained locking in those areas? In other words, have the "bang for the buck" areas been identified? Charles To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Nov 18 0:28:48 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 5A42115442 for ; Thu, 18 Nov 1999 00:28:43 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id AAA79093; Thu, 18 Nov 1999 00:28:42 -0800 (PST) (envelope-from dillon) Date: Thu, 18 Nov 1999 00:28:42 -0800 (PST) From: Matthew Dillon Message-Id: <199911180828.AAA79093@apollo.backplane.com> To: Charles Randall Cc: freebsd-smp@FreeBSD.ORG Subject: Re: RE: Big Giant Lock progress? References: <64003B21ECCAD11185C500805F31EC0304621F4F@houston.matchlogic.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :From: Matthew Dillon [mailto:dillon@apollo.backplane.com] :> Alfred got caught up in real life work so it's been on hold for a while. : :Has anyone profiled an SMP kernel in a standard role (Web server, NFS :server, development machine, etc) and compared the points of BGL contention :with the ease (or difficulty) of more fine-grained locking in those areas? : :In other words, have the "bang for the buck" areas been identified? : :Charles There are three major areas of interest: * parallelizing within the network stack * parallelizing network interrupts and the network stack * parallelizing the cached read/write data path, so the supervisor can copy data to user processes on several cpu's at once. A whole lot of groundwork needs to happen before we can do any of this stuff, though. A previous attempt to optimizing just #3 in uiomove did not produce very good results, mainly oweing to the bgl being held too long in other places. There are also some neat optimizations that can be done, especially with the simplelocks. For example, when unlocking a simplelock you do not need to used a locked instruction or even a cmpexg instruction, because you already own the lock and nobody else can mess with it. Nor do you need to use a locked assembly instruction when bumping the ref count on a simplelock you already hold. I think I am going to commit those even without Alfred's work, once I separate them out and have a little time, because they at least double the speed of the simplelocks. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Nov 18 2:15:17 1999 Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 4491A15102 for ; Thu, 18 Nov 1999 02:15:14 -0800 (PST) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id CAA06724; Thu, 18 Nov 1999 02:41:23 -0800 (PST) Date: Thu, 18 Nov 1999 02:41:23 -0800 (PST) From: Alfred Perlstein To: Matthew Dillon Cc: Charles Randall , freebsd-smp@FreeBSD.ORG Subject: Re: RE: Big Giant Lock progress? In-Reply-To: <199911180828.AAA79093@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 18 Nov 1999, Matthew Dillon wrote: > :From: Matthew Dillon [mailto:dillon@apollo.backplane.com] > :> Alfred got caught up in real life work so it's been on hold for a while. > : > :Has anyone profiled an SMP kernel in a standard role (Web server, NFS > :server, development machine, etc) and compared the points of BGL contention > :with the ease (or difficulty) of more fine-grained locking in those areas? > : > :In other words, have the "bang for the buck" areas been identified? > : > :Charles > > There are three major areas of interest: > > * parallelizing within the network stack > > * parallelizing network interrupts and the > network stack > > * parallelizing the cached read/write data > path, so the supervisor can copy data > to user processes on several cpu's at > once. A fourth area that i'm most interested in for a base for the other work is working on the low level routines that require locking that's not visible, the big example is malloc which splhigh()s while in use. Although my coding hands have been busy it doesn't stop me from thinking about this stuff in my sleep. :) I've been thinking of something along the line of per-processor pools of resources with high and low watermarks to determine when to borrow/return from a global pool. This ought to reduce malloc contention quite a bit. Since a CPU never has to worry about any other CPU toucing its memory pools it doesn't need to lock anything unless the private pool is exhausted. This is discussed in Vahalia's book in re the Dynix allocator. I've also spoken to Alan Cox (from Linux) and he's explained that the way Linux deals with malloc from device drivers (*) is that there is an 'atomic' memory pool from which drivers grab memory from. (*) the problem of interrupts for those just joining the discusion is that they may cause a recursive attempt on a lock. With the bgl it's ok (exclusive counting semaphore) but with plain spinlocks it leads to deadlock if the CPU holding the lock (on let's say the malloc pool) is interrupted and the interrupt then tries to spin on the lock already held. I like this idea quite a bit (back to atomic memory pools), combined with a per-cpu pool of memory that can be grabbed in an atomic fashion we can reduce a major contention problem as well as interrupt allocations. The problem is possible pre-mature out-of-memory-situations, but I'm confident that tuning the high/low watermarks for allocations and atomic pools can make that a rare occurrance. Fifth: It's also very important that the scheduler becomes MP safe. > A whole lot of groundwork needs to happen before > we can do any of this stuff, though. A previous > attempt to optimizing just #3 in uiomove did not > produce very good results, mainly oweing to the > bgl being held too long in other places. I wasn't around when this was attempted, did the code only touch the BGL when the amount to copy was greater than let's say 2k? Or was the bgl toggled on every uiomove? > There are also some neat optimizations that > can be done, especially with the simplelocks. > For example, when unlocking a simplelock you do > not need to used a locked instruction or even > a cmpexg instruction, because you already own > the lock and nobody else can mess with it. > Nor do you need to use a locked assembly instruction > when bumping the ref count on a simplelock you > already hold. I think I am going to commit those even > without Alfred's work, once I separate them out > and have a little time, because they at least double > the speed of the simplelocks. It'd be great to get that code committed asap, it's really a keen observation and the benefit are immediate and un-obtrusive. -Alfred > > -Matt > Matthew Dillon > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Nov 18 8:43:51 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C3D8515161 for ; Thu, 18 Nov 1999 08:43:47 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA85662; Thu, 18 Nov 1999 08:43:45 -0800 (PST) (envelope-from dillon) Date: Thu, 18 Nov 1999 08:43:45 -0800 (PST) From: Matthew Dillon Message-Id: <199911181643.IAA85662@apollo.backplane.com> To: Alfred Perlstein Cc: Charles Randall , freebsd-smp@FreeBSD.ORG Subject: Re: RE: Big Giant Lock progress? References: Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :Fifth: :It's also very important that the scheduler becomes MP safe. I forgot that one. Yes, absolutely. :> we can do any of this stuff, though. A previous :> attempt to optimizing just #3 in uiomove did not :... : :I wasn't around when this was attempted, did the code only :touch the BGL when the amount to copy was greater than let's :say 2k? Or was the bgl toggled on every uiomove? BDE tried his hand at this and spent a few minutes working up a simple patch that essentially turned off the bgl during the uiomove and then turned it back on again. I messed around with it for a while and ran a bunch of tests and just didn't get the expected performance improvement. I think there was a lock inversion problem too but I'm not sure. I concluded that the problem was that there were too many other places in the code path that held the BGL and turning it off in that one place was not sufficient. : :It'd be great to get that code committed asap, it's really a keen :observation and the benefit are immediate and un-obtrusive. : :-Alfred Ok, I will. I have put the adjusted patch up for a final review at: http://www.backplane.com/FreeBSD4/ in the second section 'SMP PatchSet ....', the file is: http://www.backplane.com/FreeBSD4/smp-patch-02.diff I've been running the patch for several weeks without any problem. I will commit it tonight if nobody sees any problems. Essentially what this code does is two things: First, it gets rid of totally unnecessary argument pushes onto the stack for lock-related assembly that is only called by other assembly and already a NON-GPROF entry. Second, it optimizes the two cases that do not require a locked instruction sequence or cmpexg by making them not use a locked instruction or cmpexg: * locking when you already own the lock (e.g. recursion) * unlocking a lock That it! Optimizing this path makes the MP locking routines even more efficient then the SMP spl*() code in the case where lock recursion occurs. Since one of the things we will have to do soon is start encapsulating many blocks of code with the BGL in order to be able to start de-encapsulating it from the top-down, these optimizations will allow us to retain good SMP performance through the work plus have the added benefit of reducing the base lock/unlock overhead by a factor of 2 (the unlock becomes very cheap). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Nov 18 20:22: 3 1999 Delivered-To: freebsd-smp@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id C6A18154D4 for ; Thu, 18 Nov 1999 20:21:56 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 1D6711CA0; Fri, 19 Nov 1999 12:21:55 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Matthew Dillon Cc: Alfred Perlstein , Charles Randall , freebsd-smp@FreeBSD.ORG Subject: Re: Big Giant Lock progress? In-reply-to: Your message of "Thu, 18 Nov 1999 08:43:45 PST." <199911181643.IAA85662@apollo.backplane.com> Date: Fri, 19 Nov 1999 12:21:55 +0800 From: Peter Wemm Message-Id: <19991119042155.1D6711CA0@overcee.netplex.com.au> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Dillon wrote: > :Fifth: > :It's also very important that the scheduler becomes MP safe. > > I forgot that one. Yes, absolutely. > > :> we can do any of this stuff, though. A previous > :> attempt to optimizing just #3 in uiomove did not > :... > : > :I wasn't around when this was attempted, did the code only > :touch the BGL when the amount to copy was greater than let's > :say 2k? Or was the bgl toggled on every uiomove? > > BDE tried his hand at this and spent a few minutes working > up a simple patch that essentially turned off the bgl > during the uiomove and then turned it back on again. I > messed around with it for a while and ran a bunch of tests > and just didn't get the expected performance improvement. > I think there was a lock inversion problem too but I'm not > sure. > > I concluded that the problem was that there were too many > other places in the code path that held the BGL and turning > it off in that one place was not sufficient. > : > :It'd be great to get that code committed asap, it's really a keen > :observation and the benefit are immediate and un-obtrusive. > : > :-Alfred > > Ok, I will. I have put the adjusted patch up for a final > review at: > > http://www.backplane.com/FreeBSD4/ > > in the second section 'SMP PatchSet ....', the file is: > > http://www.backplane.com/FreeBSD4/smp-patch-02.diff > > I've been running the patch for several weeks without > any problem. I have a problem with this portion of the smp-patch-02.diff: Index: sys/lock.h =================================================================== RCS file: /home/ncvs/src/sys/sys/lock.h,v retrieving revision 1.16 diff -u -r1.16 lock.h --- lock.h 1999/08/28 00:51:50 1.16 +++ lock.h 1999/11/18 08:22:37 @@ -208,4 +208,15 @@ #endif /* NCPUS == 1 */ #endif /* !SIMPLELOCK_DEBUG */ +#ifdef SMP +void get_mplock(void); +void rel_mplock(void); +#define GET_SYSCALL_LOCK get_mplock() +#define REL_SYSCALL_LOCK rel_mplock() +#else /* !SMP */ +#define GET_SYSCALL_LOCK +#define REL_SYSCALL_LOCK +#endif /* SMP */ + + #endif /* !_LOCK_H_ */ This appears to be unrelated to the MPgetlock etc code so it may not be intended to be there. However, the problem is that it looks like it's exposing more "#ifdef SMP" to modules.. This is a problem if we have to have a SMP vs non-SMP set of modules for 4.0-RELEASE, especially for things like OSS. Obviously I haven't seen the code, but please keep this in mind. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Nov 18 20:43:41 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 5FAD514CB0 for ; Thu, 18 Nov 1999 20:43:39 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA90542; Thu, 18 Nov 1999 20:43:29 -0800 (PST) (envelope-from dillon) Date: Thu, 18 Nov 1999 20:43:29 -0800 (PST) From: Matthew Dillon Message-Id: <199911190443.UAA90542@apollo.backplane.com> To: Peter Wemm Cc: Alfred Perlstein , Charles Randall , freebsd-smp@FreeBSD.ORG Subject: Re: Big Giant Lock progress? References: <19991119042155.1D6711CA0@overcee.netplex.com.au> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :I have a problem with this portion of the smp-patch-02.diff: : :Index: sys/lock.h :=================================================================== :RCS file: /home/ncvs/src/sys/sys/lock.h,v :retrieving revision 1.16 :diff -u -r1.16 lock.h :--- lock.h 1999/08/28 00:51:50 1.16 :+++ lock.h 1999/11/18 08:22:37 :@@ -208,4 +208,15 @@ : #endif /* NCPUS == 1 */ : #endif /* !SIMPLELOCK_DEBUG */ : :+#ifdef SMP :+void get_mplock(void); :+void rel_mplock(void); :... Yes, that's actually not part of my patch set, but Alfred's, thanks for pointing it out! I accidently left it in there. It will not be part of the commit. That said, I'm not sure it's possible to make modules SMP-unaware unless we commit ourselves to having dummy mplock and simplelock procedures for non-SMP kernels. i.e. real procedures that are empty instead of a #define to non-existance. Without a kernel device driver or module API, we are pretty much S.O.L. with modules already - if you don't recompile your modules when you recompile the kernel, bad things often happen. -Matt Matthew Dillon :+#define GET_SYSCALL_LOCK get_mplock() :+#define REL_SYSCALL_LOCK rel_mplock() :+#else /* !SMP */ :+#define GET_SYSCALL_LOCK :+#define REL_SYSCALL_LOCK :+#endif /* SMP */ :+ :+ : #endif /* !_LOCK_H_ */ : :This appears to be unrelated to the MPgetlock etc code so it may not be :intended to be there. However, the problem is that it looks like it's :exposing more "#ifdef SMP" to modules.. This is a problem if we have to :have a SMP vs non-SMP set of modules for 4.0-RELEASE, especially for things :like OSS. Obviously I haven't seen the code, but please keep this in mind. : :Cheers, :-Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Nov 18 21:32:26 1999 Delivered-To: freebsd-smp@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id D042B15592 for ; Thu, 18 Nov 1999 21:32:17 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id D54BE1CA0; Fri, 19 Nov 1999 13:32:15 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Matthew Dillon Cc: Alfred Perlstein , Charles Randall , freebsd-smp@FreeBSD.ORG Subject: Re: Big Giant Lock progress? In-reply-to: Your message of "Thu, 18 Nov 1999 20:43:29 PST." <199911190443.UAA90542@apollo.backplane.com> Date: Fri, 19 Nov 1999 13:32:15 +0800 From: Peter Wemm Message-Id: <19991119053215.D54BE1CA0@overcee.netplex.com.au> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Dillon wrote: > : > :I have a problem with this portion of the smp-patch-02.diff: > : > :Index: sys/lock.h > :=================================================================== > :RCS file: /home/ncvs/src/sys/sys/lock.h,v > :retrieving revision 1.16 > :diff -u -r1.16 lock.h > :--- lock.h 1999/08/28 00:51:50 1.16 > :+++ lock.h 1999/11/18 08:22:37 > :@@ -208,4 +208,15 @@ > : #endif /* NCPUS == 1 */ > : #endif /* !SIMPLELOCK_DEBUG */ > : > :+#ifdef SMP > :+void get_mplock(void); > :+void rel_mplock(void); > :... > > Yes, that's actually not part of my patch set, but Alfred's, thanks > for pointing it out! I accidently left it in there. It will not be part > of the commit. > > That said, I'm not sure it's possible to make modules SMP-unaware > unless we commit ourselves to having dummy mplock and simplelock > procedures for non-SMP kernels. i.e. real procedures that are empty > instead of a #define to non-existance. > > Without a kernel device driver or module API, we are pretty much S.O.L. > with modules already - if you don't recompile your modules when you > recompile the kernel, bad things often happen. Yes, it's a big nasty problem for how to do this efficiently.. The main thing I have in mind though is when we hit 4.x-RELEASE where each has a fixed set of binary interfaces... A lot of folks *do* run the CD release verbatum without changes, and it would be nice (if possible) to enable a single high level module to work on both SMP and non-SMP 4.x-RELEASE generic kernels. Anyway, it's just a goal that I thought it'd be worth re-mentioning.. ie: don't make SMP vs non-SMP differences if it's reasonably possible to avoid. Making some stub functions is easy.. BTW; are you aware of the Digital approach to this? If you call a stub function when smp isn't present, it modifies the calling code to NOP the call. We can do some nifty things along these lines with the loader at load time, it's ideally positioned to do this, so that the calls to the stubs never happen in the first place, assuming it's worth going that far. That won't help the register allocation distruptions but may be better than nothing. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Nov 19 2: 7:22 1999 Delivered-To: freebsd-smp@freebsd.org Received: from ns1.portal2.com (ns1.portal2.com [203.85.226.193]) by hub.freebsd.org (Postfix) with SMTP id 231BC155A0 for ; Fri, 19 Nov 1999 02:07:12 -0800 (PST) (envelope-from yusufg@outblaze.com) Received: (qmail 20448 invoked from network); 19 Nov 1999 10:06:47 -0000 Received: from yusufg.portal2.com (qmailr@203.85.226.249) by ns1.portal2.com with SMTP; 19 Nov 1999 10:06:47 -0000 Received: (qmail 6480 invoked by uid 500); 19 Nov 1999 10:07:08 -0000 Date: 19 Nov 1999 10:07:08 -0000 Message-ID: <19991119100708.6479.qmail@yusufg.portal2.com> From: Yusuf Goolamabbas To: freebsd-smp@freebsd.org Subject: Explanation re NBUS in smp config Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I was installing 3.3-RELEASE on an Intel 2U Rack Server platform today with 2 P-3 500's. http://www.intel.com/support/motherboards/server/lb440gx/index.htm It installed cleanly and I modified the kernel to allow for SMP by uncommenting these two lines in GENERIC options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O Did the usual config,make depend;make ;make install and reboot. However on reboot, the system said that it couldn't boot since NBUSSES should be 5 instead of 4. I have compiled FreeBSD on many dual CPU configs (albeit for the first time on this specific rack server model) and have never to modify NBUS from its default of 4 to 5 Can somebody explain what buses are referred to in NBUS ? The system boot cleanly when I recompiled the kernel with NBUS=5 Regards, Yusuf -- Yusuf Goolamabbas yusufg@outblaze.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Nov 19 3:13:34 1999 Delivered-To: freebsd-smp@freebsd.org Received: from gw0.boostworks.com (gw0.boostworks.com [194.167.81.213]) by hub.freebsd.org (Postfix) with ESMTP id 4D4C1152CC for ; Fri, 19 Nov 1999 03:12:57 -0800 (PST) (envelope-from root@synx.com) Received: from synx.com (root@rn.synx.com [192.1.1.241]) by gw0.boostworks.com (8.9.1/8.9.1) with ESMTP id MAA42366; Fri, 19 Nov 1999 12:07:15 +0100 (CET) Message-Id: <199911191107.MAA42366@gw0.boostworks.com> Date: Fri, 19 Nov 1999 12:07:11 +0100 (CET) From: Remy Nonnenmacher Reply-To: remy@synx.com Subject: Re: Explanation re NBUS in smp config To: yusufg@outblaze.com Cc: freebsd-smp@FreeBSD.ORG In-Reply-To: <19991119100708.6479.qmail@yusufg.portal2.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 19 Nov, Yusuf Goolamabbas wrote: > Hi, I was installing 3.3-RELEASE on an Intel 2U Rack Server platform > today with 2 P-3 500's. > > http://www.intel.com/support/motherboards/server/lb440gx/index.htm > > It installed cleanly and I modified the kernel to allow for SMP by > uncommenting these two lines in GENERIC > options SMP # Symmetric MultiProcessor Kernel > options APIC_IO # Symmetric (APIC) I/O > > Did the usual config,make depend;make ;make install and > reboot. However on reboot, the system said that it couldn't boot since > NBUSSES should be 5 instead of 4. I have compiled FreeBSD on many dual > CPU configs (albeit for the first time on this specific rack server > model) and have never to modify NBUS from its default of 4 to 5 > > Can somebody explain what buses are referred to in NBUS ? > > The system boot cleanly when I recompiled the kernel with NBUS=5 > > Regards, Yusuf Same thing here. The LB400GX uses an active PCI riser (with a PCI bridge). Maybe it's time to go NBUS=6 by default since 2U boxes will use more and more PCI busses. Someone to commit this ? Thanks. RN. IaM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Nov 19 7:34:25 1999 Delivered-To: freebsd-smp@freebsd.org Received: from midget.dons.net.au (daniel.lnk.telstra.net [139.130.137.70]) by hub.freebsd.org (Postfix) with ESMTP id 2382C15170 for ; Fri, 19 Nov 1999 07:34:13 -0800 (PST) (envelope-from darius@dons.net.au) Received: from guppy.dons.net.au (guppy.dons.net.au [203.31.81.9]) by midget.dons.net.au (8.9.3/8.9.1) with ESMTP id WAA00841; Fri, 19 Nov 1999 22:26:51 +1030 (CST) (envelope-from darius@dons.net.au) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199911191107.MAA42366@gw0.boostworks.com> Date: Fri, 19 Nov 1999 22:25:34 +1030 (CST) From: "Daniel J. O'Connor" To: Remy Nonnenmacher Subject: Re: Explanation re NBUS in smp config Cc: freebsd-smp@FreeBSD.ORG, yusufg@outblaze.com Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 19-Nov-99 Remy Nonnenmacher wrote: > Same thing here. The LB400GX uses an active PCI riser (with a PCI > bridge). Maybe it's time to go NBUS=6 by default since 2U boxes will use > more and more PCI busses. So presumably having more specified than actually exist doesn't break anything? (Well apart from using a little more memory it appears) Is it not possible to make it dynamic, or aren't we allowed to call malloc in when doing this stuff? --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Nov 19 8:51:53 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 7427715681 for ; Fri, 19 Nov 1999 08:51:51 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA95544; Fri, 19 Nov 1999 08:51:37 -0800 (PST) (envelope-from dillon) Date: Fri, 19 Nov 1999 08:51:37 -0800 (PST) From: Matthew Dillon Message-Id: <199911191651.IAA95544@apollo.backplane.com> To: Peter Wemm Cc: Alfred Perlstein , Charles Randall , freebsd-smp@FreeBSD.ORG Subject: Re: Big Giant Lock progress? References: <19991119042155.1D6711CA0@overcee.netplex.com.au> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, the code's been committed. Excellent! Thanks for the review! -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Nov 19 10:46: 5 1999 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 8E244150E9 for ; Fri, 19 Nov 1999 10:45:59 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from p138-ts5.syd2.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id FAA31737; Sat, 20 Nov 1999 05:52:47 +1100 Date: Sat, 20 Nov 1999 05:45:34 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Matthew Dillon Cc: Alfred Perlstein , Charles Randall , freebsd-smp@FreeBSD.ORG Subject: Re: RE: Big Giant Lock progress? In-Reply-To: <199911181643.IAA85662@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > :I wasn't around when this was attempted, did the code only > :touch the BGL when the amount to copy was greater than let's > :say 2k? Or was the bgl toggled on every uiomove? > > BDE tried his hand at this and spent a few minutes working > up a simple patch that essentially turned off the bgl > during the uiomove and then turned it back on again. I It wasn't me. ISTR luoqi working on this. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Nov 19 10:53:16 1999 Delivered-To: freebsd-smp@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 3C8791566F for ; Fri, 19 Nov 1999 10:53:09 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id NAA00533; Fri, 19 Nov 1999 13:51:51 -0500 (EST) (envelope-from luoqi) Date: Fri, 19 Nov 1999 13:51:51 -0500 (EST) From: Luoqi Chen Message-Id: <199911191851.NAA00533@lor.watermarkgroup.com> To: bde@zeta.org.au, dillon@apollo.backplane.com Subject: Re: RE: Big Giant Lock progress? Cc: bright@wintelcom.net, crandall@matchlogic.com, freebsd-smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > It wasn't me. ISTR luoqi working on this. > > Bruce > Me neither. It's probably dyson... -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Nov 19 11: 6: 0 1999 Delivered-To: freebsd-smp@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id BDCDA155E6 for ; Fri, 19 Nov 1999 11:05:48 -0800 (PST) (envelope-from alc@cs.rice.edu) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id NAA22563; Fri, 19 Nov 1999 13:05:21 -0600 (CST) Date: Fri, 19 Nov 1999 13:05:20 -0600 From: Alan Cox To: Luoqi Chen Cc: bde@zeta.org.au, dillon@apollo.backplane.com, bright@wintelcom.net, crandall@matchlogic.com, freebsd-smp@freebsd.org Subject: Re: RE: Big Giant Lock progress? Message-ID: <19991119130520.C10165@cs.rice.edu> References: <199911191851.NAA00533@lor.watermarkgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us In-Reply-To: <199911191851.NAA00533@lor.watermarkgroup.com>; from Luoqi Chen on Fri, Nov 19, 1999 at 01:51:51PM -0500 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Nov 19, 1999 at 01:51:51PM -0500, Luoqi Chen wrote: > > It wasn't me. ISTR luoqi working on this. > > > > Bruce > > > Me neither. It's probably dyson... > I recall a thread between dyson and julian on this topic. Julian did a fair bit of (performance) testing. Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Nov 19 11: 8:38 1999 Delivered-To: freebsd-smp@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 2DE8D14CE0 for ; Fri, 19 Nov 1999 11:08:31 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id LAA61485; Fri, 19 Nov 1999 11:08:15 -0800 (PST) Date: Fri, 19 Nov 1999 11:08:14 -0800 (PST) From: Julian Elischer To: Bruce Evans Cc: Matthew Dillon , Alfred Perlstein , Charles Randall , freebsd-smp@FreeBSD.ORG Subject: Re: RE: Big Giant Lock progress? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org it was john dyson On Sat, 20 Nov 1999, Bruce Evans wrote: > > :I wasn't around when this was attempted, did the code only > > :touch the BGL when the amount to copy was greater than let's > > :say 2k? Or was the bgl toggled on every uiomove? > > > > BDE tried his hand at this and spent a few minutes working > > up a simple patch that essentially turned off the bgl > > during the uiomove and then turned it back on again. I > > It wasn't me. ISTR luoqi working on this. > > Bruce > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Nov 19 11:16:44 1999 Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 28F7B14CE0 for ; Fri, 19 Nov 1999 11:16:41 -0800 (PST) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id LAA25231; Fri, 19 Nov 1999 11:42:55 -0800 (PST) Date: Fri, 19 Nov 1999 11:42:55 -0800 (PST) From: Alfred Perlstein To: Julian Elischer Cc: Bruce Evans , Matthew Dillon , Charles Randall , freebsd-smp@FreeBSD.ORG Subject: Re: RE: Big Giant Lock progress? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 19 Nov 1999, Julian Elischer wrote: > On Sat, 20 Nov 1999, Bruce Evans wrote: > > > > :I wasn't around when this was attempted, did the code only > > > :touch the BGL when the amount to copy was greater than let's > > > :say 2k? Or was the bgl toggled on every uiomove? > > > > > > BDE tried his hand at this and spent a few minutes working > > > up a simple patch that essentially turned off the bgl > > > during the uiomove and then turned it back on again. I > > > > It wasn't me. ISTR luoqi working on this. > > > > it was john dyson > I'm still wondering about my question though, was the lock selectively removed only for large transfers? Or for each and every transfer? I'm just trying to laz^H^H^H^H avoid duplicate work. :) -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Nov 19 11:32:43 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0219D15598 for ; Fri, 19 Nov 1999 11:32:41 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA01752; Fri, 19 Nov 1999 11:32:38 -0800 (PST) (envelope-from dillon) Date: Fri, 19 Nov 1999 11:32:38 -0800 (PST) From: Matthew Dillon Message-Id: <199911191932.LAA01752@apollo.backplane.com> To: Alan Cox Cc: Luoqi Chen , bde@zeta.org.au, bright@wintelcom.net, crandall@matchlogic.com, freebsd-smp@FreeBSD.ORG Subject: Re: RE: Big Giant Lock progress? References: <199911191851.NAA00533@lor.watermarkgroup.com> <19991119130520.C10165@cs.rice.edu> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> > :> > Bruce :> > :> Me neither. It's probably dyson... :> : :I recall a thread between dyson and julian on this topic. Julian :did a fair bit of (performance) testing. : :Alan Ah yes... it was John. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Nov 19 11:33:39 1999 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id B5A6A1568E for ; Fri, 19 Nov 1999 11:33:37 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA01781; Fri, 19 Nov 1999 11:33:36 -0800 (PST) (envelope-from dillon) Date: Fri, 19 Nov 1999 11:33:36 -0800 (PST) From: Matthew Dillon Message-Id: <199911191933.LAA01781@apollo.backplane.com> To: Alfred Perlstein Cc: Julian Elischer , Bruce Evans , Charles Randall , freebsd-smp@FreeBSD.ORG Subject: Re: RE: Big Giant Lock progress? References: Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :I'm still wondering about my question though, was the lock selectively :removed only for large transfers? Or for each and every transfer? : :I'm just trying to laz^H^H^H^H avoid duplicate work. :) : :-Alfred I don't remember. It was just a quick hack, don't worry about it. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message