Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 2 Feb 1997 20:36:36 +0900 (JST)
From:      Michael Hancock <michaelh@cet.co.jp>
To:        netdev@roxanne.nuclecu.unam.mx, "David S. Miller" <davem@jenolan.rutgers.edu>
Cc:        roque@di.fc.ul.pt, freebsd-smp@freebsd.org
Subject:   Re: SMP
Message-ID:  <Pine.SV4.3.95.970202202503.2569D-100000@parkplace.cet.co.jp>
In-Reply-To: <199701311231.HAA15221@jenolan.caipgeneral>

next in thread | previous in thread | raw e-mail | index | archive | help
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






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.970202202503.2569D-100000>