From owner-freebsd-hackers@FreeBSD.ORG Wed Feb 23 19:04:42 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1C2A16A4CE for ; Wed, 23 Feb 2005 19:04:42 +0000 (GMT) Received: from mail24.sea5.speakeasy.net (mail24.sea5.speakeasy.net [69.17.117.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id A665543D31 for ; Wed, 23 Feb 2005 19:04:42 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 14367 invoked from network); 23 Feb 2005 19:04:42 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 23 Feb 2005 19:04:42 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j1NJ4aev024456; Wed, 23 Feb 2005 14:04:37 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Andrey Simonenko Date: Wed, 23 Feb 2005 13:18:26 -0500 User-Agent: KMail/1.6.2 References: <000801c51327$0e2bf020$58e243a4@ash> <200502221534.41979.jhb@FreeBSD.org> <20050223140017.GA256@pm514-9.comsys.ntu-kpi.kiev.ua> In-Reply-To: <20050223140017.GA256@pm514-9.comsys.ntu-kpi.kiev.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502231318.27002.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: freebsd-hackers@FreeBSD.org cc: Ashwin Chandra Subject: Re: Kernel monitor, the return X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2005 19:04:43 -0000 On Wednesday 23 February 2005 09:00 am, Andrey Simonenko wrote: > On Tue, Feb 22, 2005 at 03:34:41PM -0500, John Baldwin wrote: > > You don't need sched_lock to check PS_INMEM, proc lock is sufficient > > (PS_INMEM is magic this way). > > I suggested the author of the original letter to get lock on sched_lock, > because statclock() modifies ru_idrss and ru_isrss values and that > values are read in that kproc. Having read some code in the kernel, > now I think that lock on sched_lock is needed only before reading > ru_idrss and ru_isrss for current thread. Am I right? (at least > getrusage() does in this way.) > > In private letters we found that it is better to use _PHOLD/_PRELE > for that task. Well, the proc lock protects the p_stats pointer. There isn't a lock protecting the reading of the ru_* variables because getting the lock wouldn't actually buy you anything. It's a race that it doesn't hurt to lose. _PHOLD() can be very expensive on 5.x as if the process is swapped out it is going to block until the process is swapped back in. Just locking proc lock and skipping if PS_INMEM is clear is going to be a lot quicker. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org