From owner-svn-src-all@FreeBSD.ORG Wed Jan 22 17:20:29 2014 Return-Path: Delivered-To: svn-src-all@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 46C35724; Wed, 22 Jan 2014 17:20:29 +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 197FB1EB0; Wed, 22 Jan 2014 17:20:29 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6E8DFB945; Wed, 22 Jan 2014 12:20:25 -0500 (EST) From: John Baldwin To: Scott Long Subject: Re: svn commit: r260898 - head/sys/kern Date: Wed, 22 Jan 2014 11:33:21 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201401200159.s0K1xa5X012123@svn.freebsd.org> <201401211126.18930.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Message-Id: <201401221133.22142.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 22 Jan 2014 12:20:25 -0500 (EST) Cc: src-committers@freebsd.org, Neel Natu , svn-src-all@freebsd.org, Rui Paulo , svn-src-head@freebsd.org, Alexander Kabaev X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 17:20:29 -0000 On Tuesday, January 21, 2014 5:12:30 pm Scott Long wrote: >=20 > On Jan 21, 2014, at 9:26 AM, John Baldwin wrote: >=20 > > On Monday, January 20, 2014 5:18:44 pm Alexander Kabaev wrote: > >> On Mon, 20 Jan 2014 11:32:29 -0500 > >> John Baldwin wrote: > >>=20 > >>> 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 > >>>>>=20 > >>>>> Log: > >>>>> Bump up WITNESS_COUNT from 1024 to 1536 so there are sufficient > >>>>> entries for > >>>>> WITNESS to actually work. > >>>>=20 > >>>> This value should be automatically tuned... > >>>=20 > >>> 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. > >>>=20 > >>> --=20 > >>> John Baldwin > >>=20 > >> As + * MAXCPU, as evidently most recent > >> overflows reported were caused by jacking MAXCPU up from its default > >> value?=20 > >=20 > > 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). >=20 > Why shouldn=92t they have a driver and device name? Wouldn=92t it help i= dentify > possible deadlocks from driver instances calling into each other? It prevents that. Let's say you have twe0 and twe1 and you use 'twe0 I/O' and 'twe1 I/O' for the locks. If you lock 'twe1 I/O' after 'twe0 I/O' WITNESS will happily just create a new known lock order and not complain. It will only complain if later during the same uptime you later acquire 'twe0 I/O' after 'twe1 I/O'. If instead you name the lock 'twe I/O', then the first time you try to acquire a second 'twe I/O' lock, WITNESS will complain (and in general drivers shouldn't be calling into each other, so we want them to complain the first time). This is why we have the MTX_NETWORK_LOCK hack for driver transmit ring locks, so that WITNESS uses a single set of lock order relationships between transmit ring locks and other locks. =2D-=20 John Baldwin