Re: KVM PMU virtualization

[Avi Kivity <avi@redhat.com>]

On 02/26/2010 04:01 PM, Ingo Molnar wrote:
> * Avi Kivity<avi@redhat.com>  wrote:
>
>    
>> On 02/26/2010 03:31 PM, Ingo Molnar wrote:
>>      
>>> * Avi Kivity<avi@redhat.com>   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.