linux-kernel - Re: [PATCH] cpuidle: menu: use nr_running instead of cpuload for calculating perf mult

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: <4FCCEF94.6010805@linux.intel.com>
Date:	Mon, 04 Jun 2012 10:25:40 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
CC:	Vladimir Davydov <vdavydov@...allels.com>,
	Ingo Molnar <mingo@...e.hu>, Len Brown <lenb@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cpuidle: menu: use nr_running instead of cpuload for
 calculating perf mult

>> what the logic is trying to do, on a 10 km level, is to limit the damage
>> of accumulated C state exit time.
>> (I'll avoid the word "latency" here, since the real time people will
>> then immediately think this is about controlling latency response, which
>> it isn't)
> 
> But why? There's a natural limit to his, say the wakeup costs 0.2ms then
> you can only do 5k of those a second. Once you need to actually do some
> work as well this comes down.

but if you only do 100 per second, you still burn 20 msec, which can be
too much if you're performance sensitive.


> But its all idle time, you cannot be idle longer than there is a lack of
> work. So if you're idle too long (because of long exit latency) your
> work shifts and the future idle time reduces, eventually causing a lower
> C state to be used.
> 
> Also, when you notice you're waking up too soon, you can quickly ramp
> down on the C state levels.

when wakeups happen too soon, this already happens.
but that's orthogonal to some degree unfortunately.

> 
>> Now, if you're very idle for a sustained duration (e.g. low load),
>> you're assumed not sensitive to a bit of performance cost.
>> but if you're actually busy (over a longer period, not just "right
>> now"), you're assumed to be sensitive to the performance cost,
>> and what the algorithm does is make it less easy to go into the
>> expensive states.
> 
> My brain still sparks and fizzles when I read that.. it just doesn't
> compute.
> 
> What performance? performance isn't a well defined word.

for the sake of argument, lets call it the amount of work the system can
get done. (where 'work' is obviously still vague, but the software
running on the system will know what it is).

can you afford to do no work for those 20 msec every second ?
the answer to that will be "it depends", and estimating that "depends"
is what the load average value is used for.

I will totally accept that the value used right now is not the optimal
or correct value to use (as you said, the "top" type load average is not
available, which would have been much nicer).
--
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/