From owner-freebsd-current@FreeBSD.ORG Sat Jan 28 14:54:03 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 6344016A422 for ; Sat, 28 Jan 2006 14:54:03 +0000 (GMT) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp801.mail.ukl.yahoo.com (smtp801.mail.ukl.yahoo.com [217.12.12.138]) by mx1.FreeBSD.org (Postfix) with SMTP id 27D7343D48 for ; Sat, 28 Jan 2006 14:54:01 +0000 (GMT) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 53011 invoked from network); 28 Jan 2006 14:54:01 -0000 Received: from unknown (HELO w2fzz0vc01.aah-go-on.com) (thomas.sparrevohn@btinternet.com@86.133.244.63 with plain) by smtp801.mail.ukl.yahoo.com with SMTP; 28 Jan 2006 14:54:01 -0000 From: Thomas Sparrevohn To: Mike Jakubik Date: Sat, 28 Jan 2006 14:53:46 +0000 User-Agent: KMail/1.9.1 References: <20060127045553.F36B34503E@ptavv.es.net> <43D9DECF.2060101@rogers.com> In-Reply-To: <43D9DECF.2060101@rogers.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601281453.48564.Thomas.Sparrevohn@btinternet.com> Cc: current@freebsd.org, Ian FREISLICH , arch@freebsd.org, Poul-Henning Kamp , freebsd-current@freebsd.org, Alexander Leidinger Subject: Re: [TEST/REVIEW] CPU accounting patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Thomas.Sparrevohn@btinternet.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2006 14:54:03 -0000 On Friday 27 January 2006 08:50, Mike Jakubik wrote: > Kevin Oberman wrote: > > Good accounting is very important to some, but the issue of dealing with > > reduced clock speed is almost certainly of no issue when it comes to > > charging for computer use. I can't imagine any reason someone would be > > paying for CPU time on a processor not running "full out". > > > > The only time that this might be an issue is when thermal management > > takes over. I'd hope that thermal management would never kick in on a > > commercial compute server, but, if it did, the customer should, at least, > > only pay for the number of seconds the job would have run had it been > > properly cooled. (Actually, he should probably pay less as his time is > > also being wasted.) > > As a user from the 2.x days, i would much rather have the great increase > of context switching performance than super accurate cpu accounting that > i will never use. FreeBSD needs to focus on performance now. Well - Both points are correct - In regards to the thermal issues - I believe we may encounter a movement towards "Infowatt accounting" - and in regards to accounting I think it is worth to understand the limitations and challanges I would rather have a "scaleable" accounting approach e.g. there are a number of other things that could be nice to have the ability to track - but that we most likely would not want enabled by default. I am thinking about VM stats etc.