From owner-freebsd-questions@FreeBSD.ORG Sun May 24 09:47:13 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA8951065679 for ; Sun, 24 May 2009 09:47:13 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-fx0-f168.google.com (mail-fx0-f168.google.com [209.85.220.168]) by mx1.freebsd.org (Postfix) with ESMTP id 685798FC1F for ; Sun, 24 May 2009 09:47:13 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by fxm12 with SMTP id 12so2602118fxm.43 for ; Sun, 24 May 2009 02:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GvDc7cwRadfib3mvyDWLCnTTEj54abS6ymgJvl1lBSs=; b=ZkPQMNGNNfck3DQ8vDDCVFfwbfLMPlBreuV0qSZmtD0XN7Kan8mI14uk0KFzKthh+B 0rT6H6ILfhOpDRB2ZLIUOQJCkjGx5Ujo4j11aeSd06E/Q+TMAkhyHaQS6NTZ5hm9/Nk3 nAvD+hGYGAGIStFzPCo5+E2To9p3a1oIlGvAY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KF1pAwPOp35Qdt7zhkMaM/vB3GFbWvb7ecBDRR3MLM3hn+n1H3ScGlCZXdNHgcE3Q3 8ENs9B8fdbIE1XqCrcAO7NNrMMhRa6UjJ+oUplLolT7cv9nhc8X6UF/VNHJSSUV0iLTg GSi6S9LrnK9KWRAV3B55XMJGuXBbdCsoNgYCY= MIME-Version: 1.0 Received: by 10.204.118.69 with SMTP id u5mr5618224bkq.77.1243158432265; Sun, 24 May 2009 02:47:12 -0700 (PDT) In-Reply-To: <4A190E47.6080006@infracaninophile.co.uk> References: <4A18BEC8.5060506@rawbw.com> <4A18FB5B.4080902@infracaninophile.co.uk> <4ad871310905240112n6186631awd96599ab51886506@mail.gmail.com> <4A190E47.6080006@infracaninophile.co.uk> Date: Sun, 24 May 2009 05:47:12 -0400 Message-ID: <4ad871310905240247v50b44fa6pd99c22c9c6516908@mail.gmail.com> From: Glen Barber To: Matthew Seaman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-questions@freebsd.org Subject: Re: How can this 'top' command output make sense? Load over 7 and total CPU use ~5% X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2009 09:47:14 -0000 On Sun, May 24, 2009 at 5:07 AM, Matthew Seaman wrote: >> >> I thought, if it was a dual-core for example, a load average of 1.00 >> would indicate 50% CPU utilization overall (1 process using only 1 >> core)[1]. =A02.00 on a dual-core would be 100%, 3.00 on a dual-core >> would be 100% utilization, and always 1 process in the wait queue, and >> so on. > > It seems both ways have been used in different OSes, which is confusing. > A quick test of a single threaded process that will spin one CPU on a > multi-core FreeBSD box shows the value is /not/ scaled by the number of > cores. > Meaning a load average of 1.00 on a single-core versus dual-core means the same thing? I can't tell if you said what I said (or meant) with different wording, or if you said the opposite. :-) > Which means that the LA the OP was talking about is actually a lot less > alarming > than it originally appears. =A0It's clear from the top output that his ma= chine > has at least 8 cores, so a LA of 7 is really not very heavily loaded. > So in this situation, he has 1 core idle all of the time, correct? >> >> Does this affect the load average though? =A0My understanding was that >> if the CPU cannot immediately process data, the data gets put into the >> wait queue until L2 Cache (then RAM, etc, etc) returns the data to be >> processed. > > Yes it does: when a process is on the CPU and blocked waiting for IO > it does not necessarily yield the CPU to another process. =A0It depends o= n > timescales -- obviously if the CPU will have to wait milliseconds for dat= a > it makes no sense to block other processes. =A0Waiting a few microseconds= is > a different matter though: it might take that long to load up L2/L3 cache > with that processes' working data, so yielding the CPU for that sort of > delay > would mean the process never got run, which is counter productive... =A0I= t > helps if the working set is already in the L3 cache -- so having the corr= ect > amount[*] of cache RAM available is an important design criterion. Makes sense. --=20 Glen Barber