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

[Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>]

On Tue, Nov 29, 2011 at 04:28:06PM -0500, William Cohen wrote:
> 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.

So I tried to do it today but running in trouble of compiling it on
Fedora Core 16. You wouldn't have any patches floating around to make it
compile? (I used first a virgin 0.9.7 version).

Thanks!
> 
> > 
> >  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
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel