Date: Thu, 18 Nov 1999 08:43:45 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: Charles Randall <crandall@matchlogic.com>, freebsd-smp@FreeBSD.ORG Subject: Re: RE: Big Giant Lock progress? Message-ID: <199911181643.IAA85662@apollo.backplane.com> References: <Pine.BSF.4.05.9911180217540.12797-100000@fw.wintelcom.net>
index | next in thread | previous in thread | raw e-mail
: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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911181643.IAA85662>