From owner-freebsd-arch@FreeBSD.ORG Wed May 30 06:36:16 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 66C5316A421; Wed, 30 May 2007 06:36:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id DF90A13C45B; Wed, 30 May 2007 06:36:15 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c211-30-225-63.carlnfd3.nsw.optusnet.com.au [211.30.225.63]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l4U6a4D2014239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 May 2007 16:36:05 +1000 Date: Wed, 30 May 2007 16:36:05 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jeff Roberson In-Reply-To: <20070529201255.X661@10.0.0.1> Message-ID: <20070530161912.P12540@besplex.bde.org> 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: rusage breakdown and cpu limits. 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, 30 May 2007 06:36:16 -0000 On Tue, 29 May 2007, Jeff Roberson wrote: > On Wed, 30 May 2007, Bruce Evans wrote: > >> On Tue, 29 May 2007, Jeff Roberson wrote: >>> The thing that will protect mi_switch() is not process global. I want to >>> keep process global locks out of mi_switch() or we reduce concurrency for >>> multi-threaded applications. >> >> This became clearer with patches and would have been clearer with >> (smaller) diffs in mail -- mi_switch() still needs locking but it isn't >> sched locking. > > Hopefully you see the value in my approach now? I don't think it's turning > out so badly, except for some details which need refining. It certainly make > mi_switch() and statclock() cleaner. And hopefully we can remove more code > from ast() and mi_switch() by changing the cpu limits. Yes, it shows promise. I like the possibility of fixing the stats for other CPUs in calcru() in a general way. The aggregation points also give a good place to fix the scaling by the cputick frequency. The cputick frequency may be variable, so the current frequency should not be used to scale all previously recorded ticks. Bruce