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