From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 1 18:05:38 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 615B51065675 for ; Thu, 1 Dec 2011 18:05:38 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id E5EF08FC14 for ; Thu, 1 Dec 2011 18:05:37 +0000 (UTC) Received: by eekc13 with SMTP id c13so1974066eek.13 for ; Thu, 01 Dec 2011 10:05:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=G+AVjakzmviBjzPceSyMY0pEQ7S+OKbXBS/CIsZdy1E=; b=jexqxHIOYGzAVh3IKaRm13gcBKPBnFJ8sasIn2tgaMA18FKNd9+RRGImnlQ8c9bAjE sHckpCWNdXV/ObKWj4Rii6qHNtgkSeY7/yHvqITfiIaUw7sf8hlOYGkzqTef3Ih51oEF /f1Mug1U+4DxDP5wdAJyB43lsjFhSM5uRHmeM= Received: by 10.227.198.142 with SMTP id eo14mr3335279wbb.28.1322762736810; Thu, 01 Dec 2011 10:05:36 -0800 (PST) Received: from DataIX.net (ppp-21.214.dialinfree.com. [209.172.21.214]) by mx.google.com with ESMTPS id fk3sm6644839wbb.10.2011.12.01.10.05.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 10:05:35 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id pB1I5RZs068228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Dec 2011 13:05:27 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id pB1I5MLQ068227; Thu, 1 Dec 2011 13:05:22 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Thu, 1 Dec 2011 13:05:22 -0500 From: Jason Hellenthal To: Steven Hartland Message-ID: <20111201180522.GA67513@DataIX.net> References: <547298A3C38F407887E1AAAAC487DF6D@multiplay.co.uk> <20111201065722.GA97051@DataIX.net> <1A338C6C470940B386C307641E350A3E@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1A338C6C470940B386C307641E350A3E@multiplay.co.uk> Cc: freebsd-hackers@freebsd.org 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 18:05:38 -0000 On Thu, Dec 01, 2011 at 10:44:58AM -0000, 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. I agree > > 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%? > Yeah I realize that but it still would lead you to believe that if a proccessor has 4 cores on the same die then total for each core could only be 25% usage. And the usage for a proccess only consuming full usage of 1 core is 100%. But you can start firefox on a single uniproccessor and like stated above see large usage percents near 338% or greater which is impossible and leads me to believe were forcing calculation for the entire proccess of threads onto tthread 0. This makes accounting pretty difficult.