Date: Thu, 01 Dec 2011 13:42:56 +0100 From: Damien Fleuriot <ml@my.gd> To: freebsd-hackers@freebsd.org Subject: Re: Invalid memory stats from vmstat and sysctl vm.vmtotal? Message-ID: <4ED77650.6050409@my.gd> In-Reply-To: <1A338C6C470940B386C307641E350A3E@multiplay.co.uk> References: <547298A3C38F407887E1AAAAC487DF6D@multiplay.co.uk> <20111201065722.GA97051@DataIX.net> <1A338C6C470940B386C307641E350A3E@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/1/11 11:44 AM, Steven Hartland wrote: > ----- Original Message ----- From: "Jason Hellenthal" <jhell@DataIX.net> > >> This goes along with the thoughts I had about 4 months ago tending to >> some >> zfs statistics as well top showing greater than 100% actual CPU usage. >> This >> is a big pet peave of mine. Its like saying you ate 134% of a bannanna >> when >> in all reallity it is impossible. You can never have more than 100% >> usage of >> anything and when seen is a clear notice that some math is considerably >> incorrect leading to other such miscalculations to be performed. >> Things like >> the above already have checks in place that ensure no boundries are being >> crossed/overflowed or underrun but it surely makes processing results >> building >> future products a bitch. One instance is the calculation of threads >> for example >> firefox can be seen using upto or more 338% of the CPU. Thats >> impossible its >> like saying anyones CPU grew by 400%. > > I could understand a bit of overflow as stats are snapshots which may not > be instuntanious, but 31GB instead of under 8GB is hardly a rounding > issue / > overflow. > > With respect to top showing greater than 100% by how much are you talking? > Do your realise that each core = 100%? So if you have a quad core your > system > total will be 400% not 100%? > That's his point, you cannot use 400% of a system as a whole, his point is that top should report 100% where each core accounts for 25%
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ED77650.6050409>