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