Re: [Xen-devel] Xenoprof in an HVM domain

["Ray Bryant" <raybry@xxxxxxxxxxxxxxxxx>]

On Thursday 25 May 2006 16:44, Santos, Jose Renato G wrote:
> If you partition the perf counters and do not share them you still need
> to enable/disable them on context switch. Otherwise you would be
> counting events that happen when other domains are running. Probably
> saving and restoring counters should not be much more expensive than
> disabling/enabling them.

Good point.   I don't know what the trade off is there. 

One other issue that worries me here is counter interference -- e. g. suppose 
we are measuring cache misses.   Then if another domain has been scheduled in 
the meantime it can wash the measured domain's data out of the cache and 
cause a lot of unexpected misses in the measured domain.   Offhand, I don't 
know of a good way to fix this other than to pin the measured domain to its 
cpu's for the duration of the measurement experiment.   Of course, there's 
still the pesky issue of interrupt service routines running in the hypervisor 
and causing cache damage there as well, or of dom0 getting invovled to do 
some I/O for the measured domain.

> Even if this is not true we could still do lazy save/restore similar to
> what is done with FPU registers. Thus we would only need to save and
> restore the counters when needed and only the counters being used. If
> you use counters in only one domain, overhead with full perf counter
> virtualization would be equivalent to your approach with the advantage
> of transparency to the guest (no need to ask for resources, etc.). If
> you use perf counters in multiple domains you may have additional
> overhead of saving/restoring them, but I think that is more than
> compensated by a more powerfull abstraction.
>

Yes.

> I think full virtualization should be the first option. Only if overhead
> proves to be very painfull we should consider an alternative. Not the
> other way around...

I agree.

> Of course, gathering some data on the overhead of saving/restoring
> counters would help clarify this.
>

Sounds like some work TBD here.   If there were only more time in the day.  

Best Regards,
-- 
Ray Bryant
AMD Performance Labs                   Austin, Tx
512-602-0038 (o)                 512-507-7807 (c)


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