Peter Hofer wrote:
Actually, I'm not really after highly accurate timing or resource usage data. What I actually want is to estimate how much particular processes or threads in a guest VM are affected by time stolen by the hypervisor. My idea is to see what fractions of the entire guest's user and system time over short periods are consumed by which tasks, and then attribute the steal time recorded in the same period to them, at the same ratios. The emphasis here being strongly on the word "estimate" ;)
I think your best bet is with the hyper-threads off. Hyper-threads aren't real threads for most code even though the kernel does have code to try to optimize their scheduling. For them to benefit, your code has to pretty much all be executing out of cache, and only some operations can be done in parallel in another hyperthread. I could see the possibility of ticks being allocated to hyperthreads that overlap x% with the other hyperthread on the same core, and ending up with more user ticks than overall ticks. Maybe the # of greater ticks w/hyperthreads is related to howmuch extra cpu cycles are made available with hyperthreading (but I think that's optimistic given the benchmark). I.e. you couldn't expect 2x ticks in 1x time from hyperthreads as they can't utilize the full cpu. Vs. w/multi core, you get N-x cpu time/real time where N=#cores ... so software that shows cpu time/realtime as a %will show, for 4 cores, up to 400% usage.. The bad habit, mostly intro'd by MS, of dropping the number of cores loses information and precision -- to the point on a 1024-cpu processor, 10 fully loaded coreds would only show 1% cpu usage on a MS machine... something indistinguishable from the noise level. I suspect your hyperviser overhead will correlate to the number of VM's contending for resources, with lowest overhead for 1:1 mappings. Good luck... -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org