lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200905282020.09667.okir@suse.de>
Date:	Thu, 28 May 2009 20:20:09 +0200
From:	Olaf Kirch <okir@...e.de>
To:	David Newall <davidn@...idnewall.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...hat.com,
	Andreas Gruenbacher <agruen@...e.de>
Subject: Re: CFS Performance Issues

On Thursday 28 May 2009 17:49:06 David Newall wrote:
> > I see this:
> >
> > ./slice 16
> >     avg slice:  1.12 utime: 216263.187500
> > ...
> > Any insight you can offer here is greatly appreciated!
> >   
> 
> About that: avg slice is in nsec, not msec (the old, off-by-one-million
> bug), and utime, also an average, is in usec.

I'm not sure I'm following what you're saying.

The test program uses getrusage(SELF) to get the utime, which is in
microseconds.

For the average time slice, it takes ru_ninvcsw, ie the number of involuntary
context switches as reported by getrusage, and computes

	utime / ninvcsw / 1000

which is a millisecond quantity.

> The first result indicates 1.12 nsec per context switch,  193 context
> switches and 346% CPU utilisation.  You must have at least four CPU

Consider the first line a bogon - it's crap resulting from variables not being
initialized with proper values the first time around. This machine is actually a
core duo, and as you notice, most of the time the numbers add up to
roughly 200% CPU utilization.

But you're right that it sometimes reports more than 200% is actually
a bug in the test case - it's not guaranteed that we're taking the samples
always exactly 1 second apart, so the utime needs to be scaled by the
elapsed wall time.

I'll fix that and come back

Olaf
-- 
Neo didn't bring down the Matrix. SOA did.
				--soafacts.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ