From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Vladimir Davydov <vdavydov@parallels.com>,
Ingo Molnar <mingo@elte.hu>, Len Brown <lenb@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cpuidle: menu: use nr_running instead of cpuload for calculating perf mult
Date: Mon, 04 Jun 2012 17:26:08 +0200 [thread overview]
Message-ID: <1338823568.28282.79.camel@twins> (raw)
In-Reply-To: <4FCCD0CD.8080700@linux.intel.com>
On Mon, 2012-06-04 at 08:14 -0700, Arjan van de Ven wrote:
> On 6/4/2012 8:08 AM, Peter Zijlstra wrote:
> > On Mon, 2012-06-04 at 06:48 -0700, Arjan van de Ven wrote:
> >> it's not about busy, it's about performance sensitive.
> >> it's not a super nice proxy, no argument, but it's one of the few long
> >> term ones we have.
> >>
> > I'm still not seeing how it makes any sense at all. Is there an actual
> > workload here this matters?
>
> yes there are, mostly server ones.
OK, so pick one that cares, and try creating a heuristic based on wakeup
history or whatever.
> the problem isn't an individual idle, it's that the 100us-200us
> latencies add up if you go in and out repeatedly, when the system is in
> a situation where it is sensitive to performance (which is not an
> instant thing, this is a "over the long run we're busy" thing)...
> ... they become a real factor.
Right, but since you're inflating idle time, the work will be displaced
and will complete later. This should result in your idle time est
shrinking.
I'm just not buying load actually matters or works, if there's lots of
idle time load history should be low, if there's not a lot of idle time,
you're busy (per definition) and again load isn't important.
next prev parent reply other threads:[~2012-06-04 15:26 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-04 10:24 [PATCH] cpuidle: menu: use nr_running instead of cpuload for calculating perf mult Vladimir Davydov
2012-06-04 10:32 ` Peter Zijlstra
2012-06-04 10:50 ` Vladimir Davydov
2012-06-04 13:13 ` Arjan van de Ven
2012-06-04 13:45 ` Peter Zijlstra
2012-06-04 13:48 ` Arjan van de Ven
2012-06-04 15:08 ` Peter Zijlstra
2012-06-04 15:14 ` Arjan van de Ven
2012-06-04 15:26 ` Peter Zijlstra [this message]
2012-06-04 15:39 ` Arjan van de Ven
2012-06-04 16:33 ` Peter Zijlstra
2012-06-04 16:53 ` Arjan van de Ven
2012-06-04 17:08 ` Vladimir Davydov
2012-06-04 17:17 ` Peter Zijlstra
2012-06-04 17:16 ` Peter Zijlstra
2012-06-04 17:25 ` Arjan van de Ven
2012-06-04 20:31 ` Peter Zijlstra
2012-06-04 20:45 ` Arjan van de Ven
2012-06-04 21:14 ` Peter Zijlstra
2012-06-04 20:40 ` Peter Zijlstra
2012-06-05 3:48 ` Mike Galbraith
2012-06-04 13:15 ` Arjan van de Ven
2012-06-04 13:19 ` Vladimir Davydov
2012-11-27 19:02 ` Vladimir Davydov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1338823568.28282.79.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=vdavydov@parallels.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox