From owner-freebsd-arch@FreeBSD.ORG Wed Jun 6 22:31:11 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 0FD8816A41F; Wed, 6 Jun 2007 22:31:11 +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 D9C2613C45B; Wed, 6 Jun 2007 22:31:10 +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 l56MV74Q046070 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 6 Jun 2007 18:31:09 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Wed, 6 Jun 2007 15:30:49 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Bruce Evans In-Reply-To: <20070605214404.X47001@delplex.bde.org> Message-ID: <20070606152352.H606@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> <20070601154833.O4207@besplex.bde.org> <20070601014601.I799@10.0.0.1> <20070601200348.G6201@delplex.bde.org> <20070601123530.B606@10.0.0.1> <20070604160036.N1084@besplex.bde.org> <46652D17.5090903@FreeBSD.org> <20070605214404.X47001@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , 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: Wed, 06 Jun 2007 22:31:11 -0000 On Tue, 5 Jun 2007, Bruce Evans wrote: > On Tue, 5 Jun 2007, Attilio Rao wrote: > >> Yes, I always wondered why proc0_post() doesn't initialize [s,i,u]ticks >> too. >> However, could you please give a look and a try to this patch: >> http://users.gufi.org/~rookie/works/patches/schedlock/proc_post.diff >> >> and see if it solves your problem. > > 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(). 3) There is no locking around rufetch() and calcru(). calcru() may apply new rux values to an old rusage, giving inaccurate results. The solution is to either require the proc slock around both calls, or provide a new routine which does the fetch and calc while grabbing the lock itself. 4) libkvm has had the rusage support if'd out because I broke it when I removed pstats.p_ru. Do we care about rusage in libkvm? Should we go to the trouble of traversing the list of threads and sum'ing it up? Can we export some subset of the information? Does anyone use this (other than bde ;). Jeff > > ANother minor problem is that proc0_post() isn't the right place to > reset the time state except for proc0. It hacks on some of the time > state for all processes and thus for all CPUs, but only resets switchtime > and switchticks for the current CPU. Resetting of switchtime and > switchticks for startup of other CPUs now seems to be in sched_throw(). > I think this is not properly synchronous with the resetting of the > rest of the state, but the errors from this are tiny. > > Bruce >