From owner-freebsd-arch@FreeBSD.ORG Fri Jun 8 16:34:06 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 AE76916A41F; Fri, 8 Jun 2007 16:34:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 393C413C469; Fri, 8 Jun 2007 16:34:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l58GXu1m057898; Fri, 8 Jun 2007 12:33:56 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Fri, 8 Jun 2007 12:22:31 -0400 User-Agent: KMail/1.9.6 References: <20070529105856.L661@10.0.0.1> <20070606152352.H606@10.0.0.1> <20070607135511.P606@10.0.0.1> In-Reply-To: <20070607135511.P606@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706081222.32457.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 08 Jun 2007 12:33:56 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3380/Fri Jun 8 08:34:26 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Attilio Rao 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, 08 Jun 2007 16:34:06 -0000 On Thursday 07 June 2007 04:59:03 pm Jeff Roberson wrote: > On Wed, 6 Jun 2007, Jeff Roberson wrote: > > > On Tue, 5 Jun 2007, Bruce Evans wrote: > > > >> > >> This can probably be fixed more simply by calling rufetch() to reset the > >> time state in threads as a side effect. Do this before resetting the > >> state in the process. > > > > Ok, I agree with bde here, just call rufetch and this will clear each thread, > > and then you can clear the rux in the proc. > > > > I'd like to make a list of the remaining problems with rusage and potential > > fixes. Then we can decide which ones myself and attilio will resolve > > immediately to clean up some of the effect of the sched lock changes. > > > > 1) The ruadd() in thread_exit() is not safe since we're accessing another > > thread's unlocked rusage structure. Potential solution is to allocate p_ru > > as part of the proc struct and add into there, which will be protected by the > > PROC_SLOCK, which bde seemed to like better anyway. > > > > 2) We may lose information between exit1() and thread_exit() due to the way > > p_ru is initialized before we're done exiting. There also seems to be a race > > where wait() operates on a process before it's done in thread_exit() which > > means wait may return rusage information without the child added in! The > > solution will be to fix this race, and then access p_ru directly in wait(). > > The patch at http://people.freebsd.org/~jeff/rusage3.diff fixes points 1 > and 2 as well as the p_runtime iniitialization problem. This moves the > collection of child rusage back into exit1() and changes the exiting > threads to accumulate their rusage into p_ru under protection of the > process spinlock. This also removes the gross lock/unlock of proc slock > (formerly sched_lock) from wait and implements something more sensible. I think the comment explaining the race still needs to be there for future code readers so they don't remove the locking. I also don't see what you gain by moving the lock earlier. -- John Baldwin