Re: [Xen-devel] [Patch] support of lock profiling in Xen

[George Dunlap <dunlapg@xxxxxxxxx>]

On Thu, Oct 8, 2009 at 9:38 AM, Juergen Gross
<juergen.gross@xxxxxxxxxxxxxx> wrote:
> It helped me a lot for narrowing down my performance problem with a 8 vcpu
> BS2000 system (this was the main reason I made the patch).
> Finding such a problem in xentrace is quite a bit of work. xentrace produced
> over 500 MB of data in 30 seconds, while reading the xenlockprof output
> revealed the bottleneck in seconds.

Minor point, but IIRC you identified the shadow lock as the problem;
but the shadow lock covers a lot of code.  Did this patch alone tell
you what *aspect* of the shadow code was causing the problem?  That's
what xentrace was designed to do. :-)

I agree, however, that for a lot of uses, xentrace isn't the right
tool.  It does introduce a lot of memory and disk overhead.  Having
this kind of lock profiling, and sample-based profiling like oprofile
or gprof for Xen is the right tool for cases where a low-overhead
aggregate measurement is all that's necessary.

Xentrace excels when aggregates don't give you enough information, and
you need to drill down into specific sequences of events, or see how
things change over time.  It's also useful for situations where it's
inconvenient to run a test iteratively as you add aggregate
information (for instance, if it's a customer running the test or
you're looking at a problem 3-hours into a 6-hour test).  Instead of
having Xen make new aggregates, you can use the analysis tool to make
new aggregates as you need them.

 -George

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