From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 1 12:43:02 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC4471065670 for ; Thu, 1 Dec 2011 12:43:02 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 624628FC08 for ; Thu, 1 Dec 2011 12:43:01 +0000 (UTC) Received: by lahv2 with SMTP id v2so980415lah.13 for ; Thu, 01 Dec 2011 04:43:00 -0800 (PST) Received: by 10.152.135.179 with SMTP id pt19mr4373126lab.47.1322743380548; Thu, 01 Dec 2011 04:43:00 -0800 (PST) Received: from dfleuriot.local (angel.c-mal.com. [82.241.189.111]) by mx.google.com with ESMTPS id mo6sm4999129lab.11.2011.12.01.04.42.57 (version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 04:42:58 -0800 (PST) Message-ID: <4ED77650.6050409@my.gd> Date: Thu, 01 Dec 2011 13:42:56 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <547298A3C38F407887E1AAAAC487DF6D@multiplay.co.uk> <20111201065722.GA97051@DataIX.net> <1A338C6C470940B386C307641E350A3E@multiplay.co.uk> In-Reply-To: <1A338C6C470940B386C307641E350A3E@multiplay.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Invalid memory stats from vmstat and sysctl vm.vmtotal? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 12:43:02 -0000 On 12/1/11 11:44 AM, Steven Hartland wrote: > ----- Original Message ----- From: "Jason Hellenthal" > >> 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%