On 02/26/2010 04:01 PM, Ingo Molnar wrote:
* Avi Kivity<avi@xxxxxxxxxx> wrote:
On 02/26/2010 03:31 PM, Ingo Molnar wrote:
* Avi Kivity<avi@xxxxxxxxxx> wrote:
Or do you mean to define a new, kvm-specific pmu model and feed it off the
host pmu? In this case all the guests will need to be taught about it,
which raises the compatibility problem.
You are missing two big things wrt. compatibility here:
1) The first upgrade overhead a one time overhead only.
May be one too many, for certain guests. Of course it may be argued
that if the guest wants performance monitoring that much, they will
upgrade.
Yes, that can certainly be argued.
Note another logical inconsistency: you are assuming reluctance to upgrade for
a set of users who are doing _performance analysis_.
In fact those types of users are amongst the most upgrade-happy. Often they'll
run modern hardware and modern software. Most of the time they are developers
themselves who try to make sure their stuff works on the latest& greatest
hardware _and_ software.
I wouldn't go as far, but I agree there is less resistance to change
here. A Windows user certainly ought to be willing to install a new
VTune release, and a RHEL user can be convinced to upgrade from (say)
5.4 to 5.6 with new backported paravirt pmu support.
I wouldn't like to force them to upgrade to 2.6.3x though. Many of
those users will be developers of in-house applications who are trying
to understand their applications under production loads.
Certainly guests that we don't port won't be able to use this. I doubt
we'll be able to make Windows work with this - the only performance tool I'm
familiar with on Windows is Intel's VTune, and that's proprietary.
Dont you see the extreme irony of your wish to limit Linux kernel design
decisions and features based on ... Windows and other proprietary software?
Not at all. Virtualization is a hardware compatibility game. To see
what happens if you don't play it, see Xen. Eventually they to
implemented hardware support even though the pv approach is so wonderful.
If we go the pv route, we'll limit the usefulness of Linux in this
scenario to a subset of guests. Users will simply walk away and choose
a hypervisor whose authors have less interest in irony and more in
providing the features they want.
A pv approach can come after we have a baseline that is useful to all users.
2) Once a Linux guest has upgraded, it will work in the future, with _any_
future CPU - _without_ having to upgrade the guest!
Dont you see the advantage of that? You can instrument an old system on new
hardware, without having to upgrade that guest for the new CPU support.
That also works for the architectural pmu, of course that's Intel
only. And there you don't need to upgrade the guest even once.
Besides being Intel only, it only exposes a limited sub-set of hw events. (far
fewer than the generic ones offered by perf events)
Things aren't mutually exclusive. Offer the arch pmu for maximum future
compatibility (Intel only, alas), the full pmu for maximum features, and
the pv pmu for flexibility.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
