svn commit: r260898 - head/sys/kern

[John Baldwin]

On Wednesday, January 22, 2014 2:06:39 pm Alfred Perlstein wrote:
> 
> On 1/22/14, 10:14 AM, John-Mark Gurney wrote:
> > Scott Long wrote this message on Tue, Jan 21, 2014 at 15:12 -0700:
> >> On Jan 21, 2014, at 9:26 AM, John Baldwin <jhb at freebsd.org> wrote:
> >>
> >>> On Monday, January 20, 2014 5:18:44 pm Alexander Kabaev wrote:
> >>>> On Mon, 20 Jan 2014 11:32:29 -0500
> >>>> 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.  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.
> >>>>>
> >>>>> -- 
> >>>>> John Baldwin
> >>>> As <CONSTANT1> + <CONSTANT2> * MAXCPU, as evidently most recent
> >>>> overflows reported were caused by jacking MAXCPU up from its default
> >>>> value?
> >>> If raising MAXCPU changes the number of unique lock names used, then the
> >>> locks are named incorrectly.  We don't use the 'pid' in the name for
> >>> PROC_LOCK precisely so that WITNESS will treat them all the same so
> >>> that if if it learns a lock order for pid 37 it enforces the same lock
> >>> order for pid 38.  Device locks should follow a similar rule.  They
> >>> should generally not include the device name (and in some cases they
> >>> really shouldn't even have the driver name).
> >> Why shouldn?t they have a driver and device name?  Wouldn?t it help 
identify
> >> possible deadlocks from driver instances calling into each other?
> > Locks have a name and a type.  The type is used for witness, but if it
> > is NULL, the name is used.  So you could if you wanted, create a common
> > type, and then put driver/device name in name, but the passed in strings
> > to both name and type have to be stable storage (only the pointer is
> > stored), so you can't use a stack variable to construct it.
> >
> Hmm, what if locks had a pointer to a 2 element char * array, the first 
> being the name, the second the type.  That would keep the size of the 
> lock down and most locks could share a common tuple of name/type in each 
> subsystem.  This would allow us to get rid of the pending static list.
> 
> effectively:
> struct lock_object {
>          char *lo_name;          /* Individual lock name. */
>          u_int   lo_flags;
>          u_int   lo_data;                /* General class specific data. */
>          struct  witness *lo_witness;    /* Data for witness. */
> };
> 
> would change to:
> struct lock_object {
>          char **lo_name_type;          /* Individual lock 
> name[0]/type[1]. */
>          u_int   lo_flags;
>          u_int   lo_data;                /* General class specific data. */
>          struct  witness *lo_witness;    /* Data for witness. */
> };
> 
> This may be somewhat disruptive, I haven't played with how it would 
> actually change driver/etc/code.

Where would the memory for the char* array come from?

-- 
John Baldwin