From owner-freebsd-arch@FreeBSD.ORG Fri Jun 1 01:17:42 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9DA1C16A421 for ; Fri, 1 Jun 2007 01:17:42 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 467D913C487 for ; Fri, 1 Jun 2007 01:17:42 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l511HUkA077510 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 31 May 2007 21:17:36 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Thu, 31 May 2007 18:17:26 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Bruce Evans In-Reply-To: <20070531010631.N661@10.0.0.1> Message-ID: <20070531181228.W799@10.0.0.1> References: <20070529105856.L661@10.0.0.1> <200705291456.38515.jhb@freebsd.org> <20070529121653.P661@10.0.0.1> <20070530065423.H93410@delplex.bde.org> <20070529141342.D661@10.0.0.1> <20070530125553.G12128@besplex.bde.org> <20070529201255.X661@10.0.0.1> <20070529220936.W661@10.0.0.1> <20070530201618.T13220@besplex.bde.org> <20070530115752.F661@10.0.0.1> <20070531091419.S826@besplex.bde.org> <20070531010631.N661@10.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: Updated rusage patch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2007 01:17:42 -0000 On Thu, 31 May 2007, Jeff Roberson wrote: > On Thu, 31 May 2007, Bruce Evans wrote: > > I believe the sched lock locking is necessary for rux. For rusage, however, > it's only ever modified by curthread. The only races that are present when > reading without locks are potentially inconsistent rusage where the stats are > not all from a single snapshot of the program. However, the stats can > obviously change before the copy makes it back to user-space anyhow. I don't > see a real race that needs protecting. > Now that I've said all of that and committed the patch, I just realized that there is still one race that is unacceptable. When the thread exits in thread_exit() and adds the stats of both threads together we could lose changes in the still-running thread. I guess I may just leave a ru in struct proc that they are added to. In the threadlock patch I serialize thread_exit() on a per-process basis. This will be compatible with the locking there. This will also get rid of that MALLOC you didn't like at the expense of slightly bloating struct proc, which I don't like. Jeff > This is why I believe the code in exit1() is also safe although technically > it could lose some information on the way to thread_exit(). To fix this we'd > have to do the final accumulation under sched_lock the last time we lock it. > However there are other races in the proc code there that were not > immediately obvious. Also, doing the accumulation here negates the > possibility of running process accounting after p_ru is valid, which it is > not doing now. > > Related to rusage but unrelated to my patch; Why are irxss, irdss, and irsss > expressed in units of bytes*ticks of execution when rusage doesn't report the > ticks of execution and rather a timeval? Are consumers expected to sum the > timevals and then extrapolate? > > Jeff > >> >> Bruce >> > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >