From: Arjan van de Ven <arjan@linux.intel.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Rik van Riel <riel@redhat.com>, Jeremy Eder <jeder@redhat.com>,
linux-kernel@vger.kernel.org, rafael.j.wysocki@intel.com,
youquan.song@intel.com, paulmck@linux.vnet.ibm.com,
len.brown@intel.com, Vincent Guittot <vincent.guittot@linaro.org>
Subject: Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea
Date: Mon, 29 Jul 2013 06:12:58 -0700 [thread overview]
Message-ID: <51F66A5A.9060901@linux.intel.com> (raw)
In-Reply-To: <51F37290.5050101@linaro.org>
>
> The menu governor tries to deduce the next wakeup but based on events
> per cpu. That means if a task with a specific behavior is migrated
> across cpus, the statistics will be wrong.
btw this is largely a misunderstanding;
tasks are not the issue; tasks use timers and those are perfectly predictable.
It's interrupts that are not and the heuristics are for that.
Now, if your hardware does the really-bad-for-power wake-all on any interrupt,
then the menu governor logic is not good for you; rather than looking at the next
timer on the current cpu you need to look at the earliest timer on the set of bundled
cpus as the upper bound of the next wake event.
And maybe even more special casing is needed... but I doubt it.
next prev parent reply other threads:[~2013-07-29 13:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-26 17:33 RFC: revert request for cpuidle patches e11538d1 and 69a37bea Jeremy Eder
2013-07-26 18:13 ` Rik van Riel
2013-07-26 18:27 ` Arjan van de Ven
2013-07-26 18:29 ` Rik van Riel
2013-07-26 21:48 ` Rafael J. Wysocki
2013-07-27 0:36 ` Rafael J. Wysocki
2013-07-27 6:22 ` Len Brown
2013-07-27 12:10 ` Rafael J. Wysocki
2013-07-27 7:11 ` Daniel Lezcano
2013-07-29 11:49 ` Arjan van de Ven
2013-07-29 13:12 ` Arjan van de Ven [this message]
2013-07-29 14:14 ` Lorenzo Pieralisi
2013-07-29 14:29 ` Arjan van de Ven
2013-07-29 16:01 ` Lorenzo Pieralisi
2013-07-29 16:04 ` Arjan van de Ven
2013-07-27 6:43 ` Daniel Lezcano
2013-07-30 3:57 ` Youquan Song
2013-07-29 16:59 ` Jeremy Eder
2013-08-02 18:19 ` Jeremy Eder
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=51F66A5A.9060901@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=daniel.lezcano@linaro.org \
--cc=jeder@redhat.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rafael.j.wysocki@intel.com \
--cc=riel@redhat.com \
--cc=vincent.guittot@linaro.org \
--cc=youquan.song@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.