Re: [RFC v2 4/7] change kernel accounting to include steal time

Rik van Riel
2010-08-30T19:17:43Z

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