From owner-freebsd-current@FreeBSD.ORG Fri Jan 27 08:57:02 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB4F516A420; Fri, 27 Jan 2006 08:57:02 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7961943D48; Fri, 27 Jan 2006 08:57:02 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 69800E4; Fri, 27 Jan 2006 03:57:23 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 94CB88134; Fri, 27 Jan 2006 03:57:18 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2PPa-000DQf-8x; Fri, 27 Jan 2006 08:56:54 +0000 Date: Fri, 27 Jan 2006 08:56:54 +0000 From: Brian Candler To: John-Mark Gurney Message-ID: <20060127085653.GA51554@uk.tiscali.com> References: <20060125201450.GE25397@cirb503493.alcatel.com.au> <56988.1138220896@critter.freebsd.dk> <20060126101138.GA40773@uk.tiscali.com> <20060127024432.GT69162@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060127024432.GT69162@funkthat.com> User-Agent: Mutt/1.4.2.1i Cc: Peter Jeremy , Poul-Henning Kamp , current@freebsd.org, arch@freebsd.org Subject: Re: [TEST/REVIEW] CPU accounting patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 08:57:03 -0000 On Thu, Jan 26, 2006 at 06:44:32PM -0800, John-Mark Gurney wrote: > The whole point of this discussion is regarding systems that scale > back their cpu clock when not in use, and speed up when the system > is heavily used... in your example of a 1/3rd of the clock speed, > the system would magicly make the other 2/3rds of the cpu cycles > available by the auto scaling daemon... Hmm. How is that decision made - based on the amount of time spent in HLT state because there is no work to be done? My initial feeling was that if something was using 100 CPU seconds per hour, and then the clock speed is reduced by 1/3 (for any reason) I wanted to see it using 300 CPU seconds per hour, because that is an accurate representation of the usage. Also, noticing the process using (proportionately) more of the CPU resource would make me investigate why, and possibly lead me to adjust system clock settings to meet my needs better. I think what you're saying is: I'm at no risk of my CPU becoming maxed out when speed has been automatically reduced by a power-saving daemon, because it will only stay there if there is still some spare capacity (i.e. some time is regularly spent in the HLT state). If not, the daemon will keep cranking up the clock speed until there *is* some spare capacity, or until max clock speed is reached. I guess this is OK, *if* you trust the power management system to do its job properly. Unfortunately I have very bad experiences of such things. In many cases I've ended up turning off power management completely and locking everything at max clock speed. Mind you, if I do that, anything you do with scaling factors isn't going to affect me, so actually I don't really care. I'll shut up now :-) Regards, Brian.