From owner-svn-src-head@FreeBSD.ORG Thu Dec 19 15:41:17 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ACE9B856; Thu, 19 Dec 2013 15:41:17 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7A4F61CC6; Thu, 19 Dec 2013 15:41:17 +0000 (UTC) Received: from [192.168.1.73] (254C556E.nat.pool.telekom.hu [37.76.85.110]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.7) with ESMTP id rBJFellg069324 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 19 Dec 2013 07:41:08 -0800 (PST) (envelope-from julian@elischer.org) Message-ID: <52B3137A.4000805@elischer.org> Date: Thu, 19 Dec 2013 16:40:42 +0100 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: John Baldwin , Mateusz Guzik Subject: Re: svn commit: r259407 - head/sys/kern References: <201312150411.rBF4Bhtg018852@svn.freebsd.org> <201312171141.49251.jhb@freebsd.org> <20131217181745.GB7535@dft-labs.eu> <201312171434.01345.jhb@freebsd.org> In-Reply-To: <201312171434.01345.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Mateusz Guzik 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: Thu, 19 Dec 2013 15:41:17 -0000 On 12/17/13, 8:34 PM, John Baldwin wrote: > On Tuesday, December 17, 2013 1:17:45 pm Mateusz Guzik wrote: >> On Tue, Dec 17, 2013 at 11:41:49AM -0500, John Baldwin wrote: >>> On Saturday, December 14, 2013 11:11:43 pm Mateusz Guzik wrote: >>>> Author: mjg >>>> Date: Sun Dec 15 04:11:43 2013 >>>> New Revision: 259407 >>>> URL: http://svnweb.freebsd.org/changeset/base/259407 >>>> >>>> Log: >>>> proc exit: don't take PROC_LOCK while freeing rlimits >>>> >>>> Code wishing to check rlimits of some process should check whether it >>>> is exiting first, which current consumers do. >>> Does this measurably reduce contention? >>> >> No, this is just a cosmetic change I did while doing some other work >> with rlimits. >> >> It would use some more cosmetic work (e.g. no reason not to >> lim_free(p->plimit); p->p_limit = NULL) and maybe I'll get to that >> later unless this kind of stuff is unwanted. > I find it useful to leave the locking in place so it is clear that p_limit is > always written to with the lock held. If we ever got a static analyzer that > understood locking rules then leaving this locking in would reduce false > positives. When I first did locking for fields in struct proc I did it by > hand based on grepping the source tree for all uses of a field and ensuring > they were locked. I think it might be more confusing later on for another > reader to see unlocked access and then have to think about why that is safe. > leave the locks there but commented out with an explanatory comment.