Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Jan 2014 11:06:39 -0800
From:      Alfred Perlstein <alfred@freebsd.org>
To:        John-Mark Gurney <jmg@funkthat.com>,  Scott Long <scott4long@yahoo.com>
Cc:        src-committers@FreeBSD.org, Neel Natu <neel@FreeBSD.org>, John Baldwin <jhb@FreeBSD.org>, svn-src-all@FreeBSD.org, Rui Paulo <rpaulo@felyko.com>, svn-src-head@FreeBSD.org, Alexander Kabaev <kabaev@gmail.com>
Subject:   Re: svn commit: r260898 - head/sys/kern
Message-ID:  <52E016BF.80102@freebsd.org>
In-Reply-To: <20140122181443.GU75135@funkthat.com>
References:  <201401200159.s0K1xa5X012123@svn.freebsd.org> <1536225.gsjt6oXMt2@pippin.baldwin.cx> <20140120171844.69e065fb@kan.dyndns.org> <201401211126.18930.jhb@freebsd.org> <D04BF613-A78D-43B8-A22B-DA8F72D22430@yahoo.com> <20140122181443.GU75135@funkthat.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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@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@freebsd.org> wrote:
>>>>
>>>>> On Sunday 19 January 2014 18:18:03 Rui Paulo wrote:
>>>>>> On 19 Jan 2014, at 17:59, Neel Natu <neel@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.

-Alfred



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52E016BF.80102>