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>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911181643.IAA85662>