investigation of Giant usage in kernel

[Kris Kennaway]

On Tue, Mar 06, 2007 at 12:15:56AM +0000, Robert Watson wrote:
> On Sun, 4 Mar 2007, Divacky Roman wrote:
> 
> >I looked at where Giant is held in the kernel and I found these 
> >interesting things:
> >
> >1) in fs/fifofs/fifo_vnops.c we lock Giant when calling 
> >sorecieve()/sosend() this is a bandaid for fixing a race that doesnt have 
> >to exist anymore. ie. it needs some testing and can be remvoed
> 
> Hmm.  I think that conclusion is a bit premature.  Per our conversation on 
> IRC, the workaround was added back prior to a release due to our being 
> unable to resolve a very difficult to debug race condition.  There is no 
> evidence the race doesn't exist anymore: what is needed is testing to 
> determine if it does or not.  The race condition occurred under high make 
> -j load on SMP; FYI, make uses a fifo to implement a concurrency limiting 
> token scheme in order to bound total simultaneous jobs despite many make 
> instances running.
> 
> I've CC'd Kris since I know that he was able to reproduce the problem, so 
> might be able to provide advice on how to do so.

It was probably the big package dispatch makefile, which is an
enormous (20MB) makefile with all of the dependency ordering data for
the entire ports tree, which is used to dispatch builds in t he
correct order using make -j${LARGENUM}, where that is typically 60 or
so depending on the size of the client pool.  In addition about half a
dozen or more of these things might be running at any one time.

Kris