From: Andi Kleen <ak@suse.de>
To: Alexey Dobriyan <adobriyan@sw.ru>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, devel@openvz.org,
cpufreq@lists.linux.org.uk, hpa@zytor.com,
davej@codemonkey.org.uk
Subject: Re: [PATCH 1/3] Introduce cpuid_on_cpu() and cpuid_eax_on_cpu()
Date: Mon, 2 Apr 2007 14:10:29 +0200 [thread overview]
Message-ID: <200704021410.29623.ak@suse.de> (raw)
In-Reply-To: <20070402113831.GA6785@localhost.sw.ru>
On Monday 02 April 2007 13:38, Alexey Dobriyan wrote:
> They will be used by cpuid driver and powernow-k8 cpufreq driver.
>
> With these changes powernow-k8 driver could run correctly on OpenVZ kernels
> with virtual cpus enabled (SCHED_VCPU).
This means openvz has multiple virtual CPU levels? One for cpuid/rdmsr and one
for the rest of the kernel? Both powernow-k8 and cpuid attempt to schedule
to the target CPU so they should already run there. But it is some other CPU,
but when they ask your _on_cpu() functions they suddenly get a "real" CPU?
Where is the difference between these levels of virtualness?
That sounds quite fragile and will likely break often. I just rejected a similar
concept -- virtual nodes and "physical nodes" for similar reasons.
Also it has weird semantics. For example if you have multiple
virtual CPUs mapping to a single CPU then would the powernow-k8 driver
try to set the frequency multiple times on the same physical CPU? That might
go wrong actually because the CPU might not be happy to be poked again
while it is already in a frequency change. Also there is no locking
so in theory two vcpus might try to change frequency in parallel with
probably quite bad effects.
I'm sure there are other scenarios with similar problems. e.g. what
happens with microcode updates etc.?
Before adding any hacks like this I think your vcpu concept
needs to be discussed properly on l-k. For me it doesn't look like it is
something good right now though.
-Andi
next prev parent reply other threads:[~2007-04-02 12:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-02 11:38 [PATCH 1/3] Introduce cpuid_on_cpu() and cpuid_eax_on_cpu() Alexey Dobriyan
2007-04-02 12:10 ` Andi Kleen [this message]
2007-04-02 16:20 ` H. Peter Anvin
2007-04-02 16:55 ` Andi Kleen
2007-04-03 13:39 ` Alexey Dobriyan
2007-04-03 13:42 ` Andi Kleen
2007-04-03 14:55 ` Alexey Dobriyan
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=200704021410.29623.ak@suse.de \
--to=ak@suse.de \
--cc=adobriyan@sw.ru \
--cc=akpm@osdl.org \
--cc=cpufreq@lists.linux.org.uk \
--cc=davej@codemonkey.org.uk \
--cc=devel@openvz.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
/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