tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: uvm locking inconsistency



Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
> > > Contrary, I think every viable debug option (DIAGNOSTIC + LOCKDEBUG at
> > > least) should be enabled in HEAD, but disabled in release kernels. An
> > > easy way to catch obvious regression that should never enter a
> > > release kernel. The so-called HEAD is the main development branch,
> > > after all...
> > 
> > LOCKDEBUG is too expensive for a normal kernel.  eg, build.sh isn't
> > just a little slower, it's 3-10x slower.
> 
> Also, LOCKDEBUG add extra locks which serialize things, so it can actually
> hide bugs. Although LOCKDEBUG is a very usefull tool, I don't think it
> should be on by default on HEAD. DIAGNOSTIC should.

It is not the extra serialization, but the overhead of LOCKDEBUG, which
has an effect of decreased concurrency.  It means that hidden bugs can be
exposed with more concurrent machines.  For instance, if a race condition
does not happen with 2-way + LOCKDEBUG kernel, it should happen with an
8-way machine.

-- 
Mindaugas


Home | Main Index | Thread Index | Old Index