From owner-freebsd-smp Tue Aug 18 22:41:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA24154 for freebsd-smp-outgoing; Tue, 18 Aug 1998 22:41:02 -0700 (PDT) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from hermes.hrz.uni-bielefeld.de (hermes.hrz.uni-bielefeld.de [129.70.4.55]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA24146 for ; Tue, 18 Aug 1998 22:41:00 -0700 (PDT) (envelope-from lkoeller@post.uni-bielefeld.de) Received: from mitch.hrz.uni-bielefeld.de (9134@mitch.hrz.uni-bielefeld.de [129.70.4.17]) by hermes.hrz.uni-bielefeld.de (8.8.6/8.8.6) with ESMTP id HAA23729; Wed, 19 Aug 1998 07:40:44 +0200 (METDST) Received: from localhost by mitch.hrz.uni-bielefeld.de with SMTP (8.8.6/16.2) id FAA24476; Wed, 19 Aug 1998 05:40:16 GMT Message-Id: <199808190540.FAA24476@mitch.hrz.uni-bielefeld.de> X-Mailer: exmh version 2.0.2 2/24/98 From: Lars =?iso-8859-1?Q?K=F6ller?= To: Terry Lambert cc: Lars.Koeller@post.uni-bielefeld.de (Lars =?iso-8859-1?Q?K=F6ller?=), chuckr@glue.umd.edu, freebsd-smp@FreeBSD.ORG Subject: Re: Per processor load? In-reply-to: tlambert's message of Tue, 18 Aug 1998 18:38:13 -0000. <199808181838.LAA20956@usr06.primenet.com> X-Face: eCcoCV}FjV*O{6>[1$XP/e%]TJhEw2MF33dFh)^HM7Gfd=[/(4+0a$~ > > Gathering this type of statistic could be actively harmful to CPU > > > latency coming out of the HLT condition, and could be as high as 10% > > > to 20% of the systems ability to do work. > > > > The basic idea was to treat the CPU's as seperate systems each with > > it's own load. This is well known from HPUX, Linux, Solaris, ... > > They display the following in, e.g. top: > > > > System: share Tue Aug 18 07:30:58 1 998 > > Load averages: 2.42, 2.29, 2.28 > > 280 processes: 273 sleeping, 5 running, 2 zombies > > Cpu states: > > CPU LOAD USER NICE SYS IDLE BLOCK SWAIT INTR SSYS > > 0 2.62 0.4% 97.6% 2.0% 0.0% 0.0% 0.0% 0.0% 0.0% > > 1 2.22 0.8% 97.0% 2.2% 0.0% 0.0% 0.0% 0.0% 0.0% > > --- ---- ----- ----- ----- ----- ----- ----- ----- ----- > > avg 2.42 0.6% 97.2% 2.2% 0.0% 0.0% 0.0% 0.0% 0.0% Sorry, I forgot to mention this top was running on HPUX 10.20. > This basically implies a scheduler artifact; each CPU must have its own > ready-to-run queue for you to get this statistic; I'm sure that on > Solaris, at least, you have to know how to grovel /dev/kmem for the > information. > > FreeBSD is symmetric. That is, there is only one ready-to-run queue > for all processors. Anything else would either result in potential > job starvation (inequity because on one processor, the jobs you are > competing with use 75% of their quantum, being compute intensive, > and on the other, they use only 10% of their quantum, being I/O > intensive). > > ..... snip ... > > As far as INTR time goes, I notice it's not reported. This is not > surprising. In Symmetric (APIC) I/O, or "virtual wire mode", the > interrupt is directed to any available processor, lowest APIC ID > first (see the Intel MP Spec version 1.4). It's really not possible, > unless you modify the ISR to record APIC ID, and reverse look it up > (an expensive operation) on each interrupt, to determine which CPU > is actually getting the interrupt. You are right, only LOAD, USER, NICE, SYS, IDLE are displayed, the other are always zero! > > I notice the other fields are not reported as well, probably for > similar reasons. > > > > Memory: 180344K (29336K) real, 256220K (66940K) virtual, 5160K free Page# 1/26 > > > > CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMM AND > > 0 ? 19703 mcfutz 251 25 632K 116K run 6:05 80.27 80.13 schl u > > 1 ? 19721 physik 251 25 632K 112K run 4:52 49.42 49.34 proc ess > > 1 ? 5375 plond 251 25 34756K 15900K run 2173:38 46.66 46.58 l502 .exe > > Pretty obviously, there aren't two running process on that one CPU. A > CPU can be in user space in only one process at a time. 8-). Grinnnn! > I think what they are doing, since they can tell you the CPU, is either > recording what CPU they last ran on, *or*, they are reporting which of > the multiple run queues that the program is on. > > ... snip ... > > Unfortunately, displaying this information is complicated, in that > you have to know what you are displaying... I see ... better I concentrate on porting xperfmon++ to libdevstat, to bring it up with the new CAM code! Thanks again and best wishes Lars -- E-Mail: | Lars Köller Lars.Koeller@Uni-Bielefeld.DE | UNIX Sysadmin lkoeller@cc.FH-Lippe.DE | Computing Center PGP-key: | University of Bielefeld http://www.nic.surfnet.nl/pgp/pks-toplev.html | Germany ----------- FreeBSD, what else? ---- http://www.freebsd.org ------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message