From owner-svn-src-head@FreeBSD.ORG Wed Jan 22 20:29:56 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D93418F3; Wed, 22 Jan 2014 20:29:55 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AC5B71FF0; Wed, 22 Jan 2014 20:29:55 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 97A8BB964; Wed, 22 Jan 2014 15:29:54 -0500 (EST) From: John Baldwin To: Alfred Perlstein Subject: Re: svn commit: r260898 - head/sys/kern Date: Wed, 22 Jan 2014 15:27:12 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201401200159.s0K1xa5X012123@svn.freebsd.org> <20140122181443.GU75135@funkthat.com> <52E016BF.80102@freebsd.org> In-Reply-To: <52E016BF.80102@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401221527.12779.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 22 Jan 2014 15:29:54 -0500 (EST) Cc: src-committers@freebsd.org, Scott Long , Neel Natu , John-Mark Gurney , svn-src-all@freebsd.org, Rui Paulo , svn-src-head@freebsd.org, Alexander Kabaev X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 20:29:56 -0000 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 wrote: > >> > >>> On Monday, January 20, 2014 5:18:44 pm Alexander Kabaev wrote: > >>>> On Mon, 20 Jan 2014 11:32:29 -0500 > >>>> John Baldwin wrote: > >>>> > >>>>> On Sunday 19 January 2014 18:18:03 Rui Paulo wrote: > >>>>>> On 19 Jan 2014, at 17:59, Neel Natu 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 + * 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