12 messages in com.xensource.lists.xen-develRe: [Xen-devel] Xenoprof in an HVM do...
FromSent OnAttachments
Steve Dobbelstein21 Apr 2006 13:10 
Yang, Xiaowei24 Apr 2006 00:02 
Steve Dobbelstein24 Apr 2006 13:08 
Santos, Jose Renato G24 Apr 2006 13:27 
Ray Bryant25 May 2006 07:20 
Santos, Jose Renato G25 May 2006 09:43 
Ray Bryant25 May 2006 11:38 
Santos, Jose Renato G25 May 2006 14:44 
Ray Bryant25 May 2006 15:01 
Santos, Jose Renato G26 May 2006 09:55 
Stephane Eranian30 May 2006 04:58 
Santos, Jose Renato G30 May 2006 19:09 
Subject:Re: [Xen-devel] Xenoprof in an HVM domain
From:Ray Bryant (ray@mpdtxmail.amd.com)
Date:05/25/2006 03:01:41 PM
List:com.xensource.lists.xen-devel

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,