From: Dave Jones <davej@redhat.com>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: cpufreq@lists.linux.org.uk, Stefan Seyfried <seife@suse.de>,
"Nakajima, Jun" <jun.nakajima@intel.com>
Subject: Re: [PATCH] If a CPU gets onlined set the governor to the one thatis run on other CPUs
Date: Mon, 27 Nov 2006 17:10:35 -0500 [thread overview]
Message-ID: <20061127221035.GI25763@redhat.com> (raw)
In-Reply-To: <EB12A50964762B4D8111D55B764A8454EBD5D7@scsmsx413.amr.corp.intel.com>
On Mon, Nov 27, 2006 at 01:49:20PM -0800, Pallipadi, Venkatesh wrote:
> Only usage model I can think of, where having per cpu governor is
> helpful
> is with virtualization.
> Say Xen DOM 0 kernel does all the cpufreq enabling and each of the other
> guests
> asks for different governor, then DOM 0 can use per CPU governor and run
> the guests with different governor requests.
>
> Jun, who is looking at Power Management in Xen context, may have more
> some
> more thoughts on that.
I put a little thought into this (but not too much) a while ago.
The proposal I came up with involved the guests not having governors at all.
For all intents, from the guests POV, they're running 'performance'
all the time.
Meanwhile, something like ondemand in DOM 0 would do the actual decision
making, based on the activity (or lack of) in each guest. Basically instead
of ondemand looking at per-processor loadavg's, it'd need to take the loadavg
of the (potentially multiple) guests running on that CPU.
Having the guests able to control the governors could get messy when you
take multi-core CPUs into consideration and two guests running on pair of siblings
request different governors. Put the decision making into DOM0, and this problem
just goes away.
Comments?
Dave
--
http://www.codemonkey.org.uk
prev parent reply other threads:[~2006-11-27 22:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-27 21:49 [PATCH] If a CPU gets onlined set the governor to the one thatis run on other CPUs Pallipadi, Venkatesh
2006-11-27 22:10 ` Dave Jones [this message]
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=20061127221035.GI25763@redhat.com \
--to=davej@redhat.com \
--cc=cpufreq@lists.linux.org.uk \
--cc=jun.nakajima@intel.com \
--cc=seife@suse.de \
--cc=venkatesh.pallipadi@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.