From owner-freebsd-smp Sun Feb 2 03:37:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA14638 for smp-outgoing; Sun, 2 Feb 1997 03:37:10 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA14632 for ; Sun, 2 Feb 1997 03:37:06 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id LAA02818; Sun, 2 Feb 1997 11:36:36 GMT Date: Sun, 2 Feb 1997 20:36:36 +0900 (JST) From: Michael Hancock To: netdev@roxanne.nuclecu.unam.mx, "David S. Miller" cc: roque@di.fc.ul.pt, freebsd-smp@freebsd.org Subject: Re: SMP In-Reply-To: <199701311231.HAA15221@jenolan.caipgeneral> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 31 Jan 1997, David S. Miller wrote: > step 2: > > Ok, no self locking technique exists for what you are > tackling. Ok, plan B. > > At this point, you are going to go after a traditional locking > technique. But make the most of it. The traditional way > people think about this stuff for performance is to try and > make it such that less people want to lock the same stuff. > > I tend to disagree with that philosophy for certain > situations, and instead I would incourage someone to take > the following approach first. > > "Try to find a locking strategy that encourages code which > holds the lock for _extremely_ short periods of time." > > That is, strive for short holds instead of less contention. > It almost sounds like there are cases where "short holds" and "less contention" are hard to achieve. Can you give us an example? Or are you saying that spending time on contention minimization is not very fruitful. I think some key subsystems would benefit from per processor pools (less contention) and the code can still be structured for short holds. Regards, Mike Hancock