svn commit: r260898 - head/sys/kern

[John Baldwin]

On Monday, January 20, 2014 4:21:13 pm Rui Paulo wrote:
> On 20 Jan 2014, at 08:32, John Baldwin <jhb at freebsd.org> wrote:
> 
> > On Sunday 19 January 2014 18:18:03 Rui Paulo wrote:
> >> On 19 Jan 2014, at 17:59, Neel Natu <neel at FreeBSD.org> wrote:
> >>> Author: neel
> >>> Date: Mon Jan 20 01:59:35 2014
> >>> New Revision: 260898
> >>> URL: http://svnweb.freebsd.org/changeset/base/260898
> >>> 
> >>> Log:
> >>> Bump up WITNESS_COUNT from 1024 to 1536 so there are sufficient entries
> >>> for
> >>> WITNESS to actually work.
> >> 
> >> This value should be automatically tuned...
> > 
> > How do you propose to do so?  This is the count of locks initialized before 
> > witness' own SYSINIT is executed and the array it sizes is allocated 
> > statically at compile time.
> 
> Witness is never used (witness_cold) until witness_initialise() is called, right?

Yes, but we'd like to make sure that any locks initialized before then are
tracked by witness after that point.

> >  This used to not be a static array, but an
> > intrusive list embedded in locks themselves, but we decided to shave a
> > pointer off of each lock that was only used for that and to use a statically 
> > sized table instead.
> 
> Why don’t we start with a static value (say 1024) and then reinitialise and
> copy array if it doesn’t fit instead of crashing the kernel?

Where do we get the memory for the new array?  If we could malloc it, we
wouldn't have a static one.  If we could malloc, we would also call
witness_initialize() (that is what it is waiting for, the chance to call
malloc() for 'struct witness' objects).

Hmm, looking at the witness code though, this doesn't result in panics (the
one that was bumped here).  The pending list panics if it is exhausted, but
if WITNESS_COUNT is exhausted witness just turns itself off.  We could make
the pending list also just turn witness off rather than panic'ing if the
pending list panic issue is a dire one.

-- 
John Baldwin