On 08/30/2010 03:07 PM, Jeremy Fitzhardinge wrote:
On 08/30/2010 11:39 AM, Rik van Riel wrote:
On 08/30/2010 01:30 PM, Jeremy Fitzhardinge wrote:
On 08/30/2010 09:06 AM, Glauber Costa wrote:
This patch proposes a common steal time implementation. When no
steal time is accounted, we just add a branch to the current
accounting code, that shouldn't add much overhead.
How is stolen time logically any different from a CPU running slowly due
to HT or power management? Is it worth trying to handle them in the
same way? (I'm mostly picking on the "_from_hypervisor" part, since
that seems over-specific.)
Why not have a get_unstolen_time() function which just returns
sched_clock() in the normal case, but can return less?
Steal time gets you information you can act on, when
your program is running slowly.
The steal time statistic allows you to see whether the
slowdown was due to the CPU just not being fast enough,
or due to something else contending for the CPU.
This can be useful information. Apparently, it has been
useful enough that it has been implemented on s390, PPC
and Xen (pre pvops Xen).
Sure - pvops Xen has had stolen time accounting from the start (or a
very long time, at least). I think Glauber's changes are functionally
identical to Xen's existing stolen time support, but more intrusive.
I suppose HT can have similar results, but that is
also something that system administrators can see.
My comments were mostly because I though that this patch was going to
actually make the scheduler change behaviour to take stolen time into
account in scheduling decisions
I believe that happens automatically.
When time is accounted as steal time, it is NOT accounted as
to the current process user/system/..., which in turn should
help it in the scheduler.
Am I overlooking something?
--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
