linux-kernel - Re: CFS Performance Issues

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]

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/