Re: [Xen-devel] xenoprof patch for oprofile-0.9.7

[William Cohen <wcohen@redhat.com>]

On 11/28/2011 05:45 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 28, 2011 at 05:09:34PM -0500, William Cohen wrote:
>> I am rebasing Fedora rawhide oprofile package to oprofile-0.9.7. The xenoprof patches on http://xenoprof.sourceforge.net/#download look a bit dated. The newest version is for oprofile-0.9.5. 
> 
> There was one posted some time ago.. Ah:
> http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.0-xen-passive-oprofile.patch.gz
> 
> I think that ones works , thought I haven't had a chance to test it
> myself.
>>
>> I massaged the patch oprofile-0.9.5-xen.patch to apply to oprofile-.0.9.7. Attached is that updated patch. Does this look reasonable? Is there a desire to get this into upstream oprofile? Or should the xenoprof patch be dropped?
> 
> Well, the desire is to get a performance tool in upstream that works
> with Xen very very very much.
> 
> The upstream is using the 'perf' framework which is different from oprofile
> and there hasn't been any patches to take advantage of it.
> 
> So to answer your question:
>  1). Its awesome you have posted a patch. Will need to spend some time
>      with it and and with the version that was posted to see if there is
>      something missing. Sadly, the kernel patch is not very
>      upstream-compatible as is. But it will get to folks be able to
>      do some perf analysis instead of using benchmark tools.

If anyone can exercise the patch and verify that it works well with the current upstream xen, that would be greatly appreciated.

> 
>  2). In the future we need to work out the optimal performance tool. It
>      might be oprofile or it might be perf (or it might be both?!). Or
>      it might something that has not yet been posted?
> 
> You wouldn't by any chance be interested in looking at the performance
> "stuff" and figure out what is the best route/tools to use with upstream
> kernels?

There has been some discussion for oprofile to make use of the perf interfaces in future versions of oprofile. The ARM oprofile kernel driver already uses the underlying perf support in the newer kernels. Making oprofile use the perf interface directly would allow normal users to use oprofile to see what is going on with their software and it would allow better cooperative resource allocation of the performance monitoring units.  Also perf allow keeping events on a per thread basis so there would be some hope that different virtual machines could use the counters concurrently.

perf hasn't been ideal. One of the common use cases would be using perf within a virtual machine, but perf didn't handle that case for the performance monitoring hardware. in the past perf claimed it programmed the performance monitoring hardware, but gave bogus measurements. Newer kernels in guest virtual machine now indicate can't hardware perf events are "<not supported>".  

-Will


-Will




------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d