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 - and those decisions would be equally
meaningful if the slowdown was from HT, PM or stolen time. But AFAICT
this patch does nothing to that end.
J
--
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
