From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Rik van Riel <riel@redhat.com>
Cc: Glauber Costa <glommer@redhat.com>,
kvm@vger.kernel.org, avi@redhat.com, zamsden@redhat.com,
mtosatti@redhat.com, peterz@infradead.org, mingo@elte.hu
Subject: Re: [RFC v2 4/7] change kernel accounting to include steal time
Date: Mon, 30 Aug 2010 12:07:51 -0700 [thread overview]
Message-ID: <4C7C0187.7040401@goop.org> (raw)
In-Reply-To: <4C7BFACD.4030409@redhat.com>
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
next prev parent reply other threads:[~2010-08-30 19:07 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-30 16:06 [RFC v2 0/7] kvm stael time implementation Glauber Costa
2010-08-30 16:06 ` [RFC v2 1/7] change headers preparing for steal time Glauber Costa
2010-08-30 16:06 ` [RFC 1/8] Implement getnsboottime kernel API Glauber Costa
2010-08-30 16:06 ` [RFC v2 2/7] always call kvm_write_guest Glauber Costa
2010-08-30 16:06 ` [RFC 2/8] change headers preparing for steal time Glauber Costa
2010-08-30 16:06 ` [RFC 3/8] always call kvm_write_guest Glauber Costa
2010-08-30 16:06 ` [RFC v2 3/7] measure time out of guest Glauber Costa
2010-08-30 16:06 ` [RFC v2 4/7] change kernel accounting to include steal time Glauber Costa
2010-08-30 16:06 ` [RFC 4/8] measure time out of guest Glauber Costa
2010-08-30 16:06 ` [RFC 5/8] change kernel accounting to include steal time Glauber Costa
2010-08-30 16:06 ` [RFC v2 5/7] kvm steal time implementation Glauber Costa
2010-08-30 16:06 ` [RFC 6/8] " Glauber Costa
2010-08-30 16:06 ` [RFC v2 6/7] touch softlockup watchdog Glauber Costa
2010-08-30 16:06 ` [RFC v2 7/7] tell guest about steal time feature Glauber Costa
2010-08-30 16:06 ` [RFC 7/8] touch softlockup watchdog Glauber Costa
2010-08-30 16:06 ` [RFC 8/8] tell guest about steal time feature Glauber Costa
2010-08-30 17:33 ` [RFC v2 6/7] touch softlockup watchdog Jeremy Fitzhardinge
2010-08-30 18:07 ` Glauber Costa
2010-08-30 16:46 ` [RFC 5/8] change kernel accounting to include steal time Peter Zijlstra
2010-08-30 17:26 ` Glauber Costa
2010-08-30 17:30 ` [RFC v2 4/7] " Jeremy Fitzhardinge
2010-08-30 18:39 ` Rik van Riel
2010-08-30 19:07 ` Jeremy Fitzhardinge [this message]
2010-08-30 19:14 ` Peter Zijlstra
2010-08-30 19:17 ` Rik van Riel
2010-08-30 19:20 ` Peter Zijlstra
2010-08-30 19:45 ` Rik van Riel
2010-08-30 22:56 ` Jeremy Fitzhardinge
2010-08-30 23:03 ` Rik van Riel
2010-08-31 8:11 ` Peter Zijlstra
2010-09-02 18:19 ` Glauber Costa
2010-09-03 3:24 ` Jeremy Fitzhardinge
2010-09-03 7:18 ` Peter Zijlstra
2010-09-01 23:56 ` [RFC 1/8] Implement getnsboottime kernel API Zachary Amsden
2010-08-30 16:37 ` [RFC v2 0/7] kvm stael time implementation Peter Zijlstra
2010-08-30 16:45 ` Jeremy Fitzhardinge
2010-08-30 17:21 ` Glauber Costa
2010-08-30 17:20 ` Jeremy Fitzhardinge
2010-08-30 17:06 [RFC v2 0/7] kvm steal time implementation proposal Glauber Costa
2010-08-30 17:06 ` [RFC v2 4/7] change kernel accounting to include steal time Glauber Costa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C7C0187.7040401@goop.org \
--to=jeremy@goop.org \
--cc=avi@redhat.com \
--cc=glommer@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mtosatti@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=zamsden@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).