From owner-svn-src-all@FreeBSD.ORG Wed Jan 22 18:14:56 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 128D8DCB; Wed, 22 Jan 2014 18:14:56 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DD6ED1396; Wed, 22 Jan 2014 18:14:55 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s0MIEhM7061593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jan 2014 10:14:44 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s0MIEhMl061592; Wed, 22 Jan 2014 10:14:43 -0800 (PST) (envelope-from jmg) Date: Wed, 22 Jan 2014 10:14:43 -0800 From: John-Mark Gurney To: Scott Long Subject: Re: svn commit: r260898 - head/sys/kern Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 22 Jan 2014 10:14:44 -0800 (PST) Cc: src-committers@FreeBSD.org, Neel Natu , John Baldwin , 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 18:14:56 -0000 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. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."