From owner-freebsd-questions@FreeBSD.ORG Sun May 24 07:46:50 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 637DF1065672 for ; Sun, 24 May 2009 07:46:50 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id AD9658FC12 for ; Sun, 24 May 2009 07:46:49 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost [IPv6:::1]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.3/8.14.3) with ESMTP id n4O7kfR1004746; Sun, 24 May 2009 08:46:43 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp.infracaninophile.co.uk n4O7kfR1004746 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infracaninophile.co.uk; s=200708; t=1243151203; bh=BccM2Jl2usl1v1xfI2D1A946X93AqdScBbSglh0vE0I=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Cc:Content-Type:Date:From:In-Reply-To: Message-ID:Mime-Version:References:To; z=Message-ID:=20<4A18FB5B.4080902@infracaninophile.co.uk>|Date:=20S un,=2024=20May=202009=2008:46:35=20+0100|From:=20Matthew=20Seaman= 20|Organization:=20Infracaninophi le|User-Agent:=20Thunderbird=202.0.0.21=20(X11/20090420)|MIME-Vers ion:=201.0|To:=20yuri@rawbw.com|CC:=20freebsd-questions@freebsd.or g|Subject:=20Re:=20How=20can=20this=20'top'=20command=20output=20m ake=20sense?=20Load=20over=207=20and=0D=0A=20total=20CPU=20use=20~ 5%|References:=20<4A18BEC8.5060506@rawbw.com>|In-Reply-To:=20<4A18 BEC8.5060506@rawbw.com>|X-Enigmail-Version:=200.95.6|Content-Type: =20multipart/signed=3B=20micalg=3Dpgp-sha256=3B=0D=0A=20protocol=3 D"application/pgp-signature"=3B=0D=0A=20boundary=3D"------------en ig60019553DCB3B46DA915EC58"; b=IbXXZZQ5YKx6nuTlJNEmk74wU0Aj/A6TWSohuaAbeworg9OfsHnh93BpMDdudXaWz YmRsno7tvpXS7gp6ZrN7ecUUXBGVdlI+casCG5ux/X69VooH6jNL26heSpKMq16YYn 0cSw7PaBPrZLMqU8V6pUI74S/C1YjCPC87JfSpfk= X-Authentication-Warning: happy-idiot-talk.infracaninophile.co.uk: Host localhost [IPv6:::1] claimed to be happy-idiot-talk.infracaninophile.co.uk Message-ID: <4A18FB5B.4080902@infracaninophile.co.uk> Date: Sun, 24 May 2009 08:46:35 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 2.0.0.21 (X11/20090420) MIME-Version: 1.0 To: yuri@rawbw.com References: <4A18BEC8.5060506@rawbw.com> In-Reply-To: <4A18BEC8.5060506@rawbw.com> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig60019553DCB3B46DA915EC58" X-Virus-Scanned: clamav-milter 0.95.1 at happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VERIFIED,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on happy-idiot-talk.infracaninophile.co.uk 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 07:46:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig60019553DCB3B46DA915EC58 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Yuri wrote: > Look below: load over 7 and no processes take much CPU. >=20 > Yuri >=20 > 7.2-PRERELEASE, 32-bit on i7-920. >=20 >=20 >=20 > ------------------------------------------------------------ > last pid: 93192; load averages: 7.68, 6.27, =20 > 4.61 = =20 > up 2+03:11:29 20:25:24 > 204 processes: 9 running, 193 sleeping, 1 stopped, 1 zombie > CPU: 5.3% user, 0.0% nice, 0.0% system, 0.0% interrupt, 94.7% idle > Mem: 867M Active, 1684M Inact, 279M Wired, 65M Cache, 112M Buf, 92M Fre= e > Swap: 16G Total, 142M Used, 16G Free >=20 > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMM= AND > 60032 yuri 1 46 0 285M 183M select 0 41:15 0.59% Xor= g > 60400 yuri 1 4 0 12576K 9144K kqread 4 29:44 0.00%=20 > wineserver > 92982 yuri 1 44 0 53012K 16800K CPU3 3 18:50 0.00%=20 > kdeinit4 > 92986 yuri 1 44 0 53012K 16800K CPU7 7 18:48 0.00%=20 > kdeinit4 > 92988 yuri 1 107 0 53012K 16840K CPU6 6 17:22 0.00%=20 > kdeinit4 > 60104 yuri 1 44 0 132M 45860K select 0 16:58 0.00% kwi= n > 92984 yuri 1 117 0 53012K 16800K RUN 5 14:56 0.00%=20 > kdeinit4 > 60096 yuri 1 44 0 89732K 30040K select 4 10:10 0.00% kde= d4 > 93141 yuri 1 53 0 53012K 16800K CPU5 5 3:52 0.00%=20 > kdeinit4 > 93139 yuri 1 44 0 53012K 16800K CPU1 1 3:30 0.00%=20 > kdeinit4 > 60174 yuri 1 44 0 3168K 1400K select 0 1:28 0.00%=20 > ksysguardd > 450 root 1 4 0 3128K 800K select 4 0:44 0.00% dhcl= ient > 1131 messagebus 1 4 0 3344K 1384K select 4 0:40 0.00%=20 > dbus-daemon Sure. This is not an uncommon occurrence really. The load average is the number of processes in the queue for a CPU time slice averaged over 5, 10 or 15 minutes. For multi-core systems the LA is scaled by the numb= er of cores so a LA of 1.0 means all cores have active processes pretty much= continually. Now, you might think that an active process will take the CPU utilisation= to 100%, but that is not necessarily so. Some numerical applications can= do that, but purely CPU bound processes are relatively uncommon in everyd= ay usage. In actuality what happens is that the processor will need to retr= ieve data from somewhere to operate on. There's a hierarchy of data stores of= various speeds (latency, rather than bandwidth): L1 Cache > L2 Cache > L3 Cache > Main RAM > Disk > Network Where the L1 Cache is accessible in a few clock ticks (nanoseconds), Main= =20 RAM can take microseconds to access, disk can take milliseconds to access= , and Network can take 10 -- 1000s of milliseconds. Or in other words, about 9 orders of magnitude difference. So when the d= ata you need to process is too big to fit in the fastest caches, or when it c= omes from a particularly slow location or when you have a lot of active proces= ses causing context switches, then the CPU core will be making frequent IO re= quests and spending time waiting for them to be fulfilled. =20 Now, for sources like disks and network where the retrieval is much slowe= r than the typical timescale of events on the CPU the process will yield the CPU= to something else and only get a new timeslice once the IO request has been fulfilled. For an access to main RAM however that form of yielding is le= ss likely. Consequently the CPU can end up waiting for 100s of clock cycles= until it gets some bytes to process. In the mean time, other processes are als= o sitting in the queue wanting CPU time slices -- hence the high LA with low CPU ut= ilization. Scheduling CPU timeslices to make maximum use of available resources is t= he difference between a really performant OS and a disaster. A good schedul= er is the critical central piece of code around which the rest of an OS can = be constructed. Combine that with the complexity of having multiple core= s, and that threads of execution sometimes have to be moved to different cores, = and on other occasions sometimes need to stick to the same core in order to m= ake best use of resources and you will start to appreciate quite how hard it = is to write a good scheduler. Unsurprisingly, the design of such things is a m= atter of fairly impassioned debate amongst the rarified circle of people capabl= e of writing them. That sort of argument was the genesis of the FreeBSD / Dra= gonflyBSD fork a few years back. You can rest assured though that FreeBSD certainl= y does have one of the very best schedulers currently available and it is specif= ically targeted at getting the best out of the sort of multicore CPUs available = nowadays. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW --------------enig60019553DCB3B46DA915EC58 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkoY+2EACgkQ8Mjk52CukIyPVQCgibP3ynO+kof6DtZjrOxUfhkR CnoAn2g7ePoFI6VTHrYIe3MhFS3UXtNU =fh2l -----END PGP SIGNATURE----- --------------enig60019553DCB3B46DA915EC58--