12 messages in com.xensource.lists.xen-develRe: [Xen-devel] Xenoprof in an HVM do...| From | Sent On | Attachments |
|---|---|---|
| Steve Dobbelstein | 21 Apr 2006 13:10 | |
| Yang, Xiaowei | 24 Apr 2006 00:02 | |
| Steve Dobbelstein | 24 Apr 2006 13:08 | |
| Santos, Jose Renato G | 24 Apr 2006 13:27 | |
| Ray Bryant | 25 May 2006 07:20 | |
| Santos, Jose Renato G | 25 May 2006 09:43 | |
| Ray Bryant | 25 May 2006 11:38 | |
| Santos, Jose Renato G | 25 May 2006 14:44 | |
| Ray Bryant | 25 May 2006 15:01 | |
| Santos, Jose Renato G | 26 May 2006 09:55 | |
| Stephane Eranian | 30 May 2006 04:58 | |
| Santos, Jose Renato G | 30 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,
-- Ray Bryant AMD Performance Labs Austin, Tx 512-602-0038 (o) 512-507-7807 (c)
_______________________________________________ Xen-devel mailing list Xen-...@lists.xensource.com http://lists.xensource.com/xen-devel




