From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 06:03:17 2003 Return-Path: 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 3C97D16A4CE for ; Thu, 11 Dec 2003 06:03:17 -0800 (PST) Received: from franky.speednet.com.au (franky.speednet.com.au [203.57.65.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C39043D2B for ; Thu, 11 Dec 2003 06:03:14 -0800 (PST) (envelope-from andyf@speednet.com.au) Received: from hewey.af.speednet.com.au (udsl-3-062.QLD.dft.com.au [202.168.108.62])hBBE38Zu028068; Fri, 12 Dec 2003 01:03:08 +1100 (EST) (envelope-from andyf@speednet.com.au) Received: from hewey.af.speednet.com.au (hewey.af.speednet.com.au [172.22.2.17])hBBE36Gw018158; Fri, 12 Dec 2003 00:03:07 +1000 (EST) (envelope-from andyf@speednet.com.au) Date: Fri, 12 Dec 2003 00:03:06 +1000 (EST) From: Andy Farkas X-X-Sender: andyf@hewey.af.speednet.com.au To: Bruce Evans In-Reply-To: <20031211223750.N11381@gamplex.bde.org> Message-ID: <20031211234620.O15896@hewey.af.speednet.com.au> References: <20031211041048.B4201-100000@mail.chesapeake.net> <20031211223750.N11381@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Jeff Roberson cc: current@freebsd.org Subject: Re: ULE and current. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Thu, 11 Dec 2003 14:03:17 -0000 Bruce Evans wrote: > On Thu, 11 Dec 2003, Jeff Roberson wrote: > > On Thu, 11 Dec 2003, Andy Farkas wrote: > > > Jeff Roberson wrote: > > ... > > > And at this point I would expect something like: > > > > > > sh #0 using 66.3%, > > > sh #1 using 66.3%, > > > sh #2 using 66.3%, > > > idle: cpu0 to be 0%, > > > idle: cpu1 to be 0%. > > > > This is actually very difficult to get exactly right. Since all processes > > want to run all the time, you have to force alternating pairs to share the > > second cpu. Otherwise they wont run for an even amount of time. > > Perhaps add some randomness. Busting the caches every second or so > shouldn't make much difference. It happens anyway if there are more > processes. Ah, a fundamental misconceptualisation of how SMP works on my part. I'll leave it up to you guys to figure out how best to do it. I also have a quad cpu box to test with, so beware :) ... > > The vm has an idle thread that zeros pages. This is the third thread. > > > > > /0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 > > > root idle: cpu0 XXXXXXXXXXXXXXXX > > > root idle: cpu1 XXXXXXXXXXXXXXXX > > > XXXXXXXXXXXXXXXX > > No, is just cp_time[CP_IDLE] scaled incorrectly. It is bogus now that > we have actual idle processes. The scaling for the idle processes seems to > be almost correct (it is apparently scaled by the number of CPUs), but the > scaling or the value for is apparently off by a factor of the number > of CPUs. ... > > > So, where *I* get confused is that top(1) thinks that the system can be up > > > to 200% idle, whereas systat(1) thinks there are 3 threads each consuming > > > a third of 100% idleness... who is right? > > > > Both, they just display different statistics. ;-) > > Neither; they have different bugs :-). top actually seems to be > bug-free here, except it intentionally displays percentages that add > up to a multiple of 100%. This seems to be best. You just have to > get used to the percentages in the CPU stat line being scaled and the > others not being scaled. So the almost-bug in top(1) is that some CPU percentages are scaled and some are not scaled? > I now understand the case of an idle system: > > /0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 > root idle: cpu0 XXXXXXXXXXXXXXXX > root idle: cpu1 XXXXXXXXXXXXXXXX > XXXXXXXXXXXXXXXX > > This should show 50% for each "idle: cpuN" process. Yes. > Instead, it tries > to show 33.3% for each idle process including the pseudo one, but has > some rounding errors that make it display 30%. The factor of 3 to get > 33.3% instead of 2 to get 50% for the real idle processes is from > bogusly counting the pseudo-idle process. The factor of 3 to get 33.3% > instead of 1 to get 100% for the pseudo-idle process is from bogusly > counting the real idle processes. > > None of these bugs except the percentages being slightly too high are > scheduler-dependent. ps. You mentioned "jitter". Thats why I 'sleep 120' in the above tests. It tends to take about that long for top(1) to settle down. Why is that so? > > Bruce -- :{ andyf@speednet.com.au Andy Farkas System Administrator Speednet Communications http://www.speednet.com.au/