From: Dan Hecht <dhecht@vmware.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: dwalker@mvista.com, cpufreq@lists.linux.org.uk,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Con Kolivas <kernel@kolivas.org>,
Chris Wright <chrisw@sous-sol.org>,
Virtualization Mailing List <virtualization@lists.osdl.org>,
john stultz <johnstul@us.ibm.com>, Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.de>,
paulus@au.ibm.com, schwidefsky@de.ibm.com,
Rik van Riel <riel@redhat.com>, Zachary Amsden <zach@vmware.com>
Subject: Re: Stolen and degraded time and schedulers
Date: Thu, 15 Mar 2007 12:09:08 -0700 [thread overview]
Message-ID: <45F999D4.6080602@vmware.com> (raw)
In-Reply-To: <45F866AF.9060609@goop.org>
On 03/14/2007 02:18 PM, Jeremy Fitzhardinge wrote:
> Dan Hecht wrote:
>> On 03/14/2007 01:31 PM, Jeremy Fitzhardinge wrote:
>>> Dan Hecht wrote:
>>>> Sounds good. I don't see this in your patchset you sent yesterday
>>>> though; did you add it after sending out those patches?
>>> Yes.
>>>
>>>> if so, could you forward the new patch? does it explicitly prevent
>>>> stolen time from getting accounted as user/system time or does it
>>>> just rely on NO_HZ mode sort of happening to work that way (since the
>>>> one shot timer is skipped ahead for missed ticks)?
>>> Hm, not sure. It doesn't care how often it gets called; it just
>>> accumulates results up to that point, but I'm not sure if the time would
>>> get double accounted. Perhaps it doesn't matter when using
>>> xen_sched_clock().
>>>
>> I think you might be double counting time in some cases.
>> sched_clock() isn't really relevant to stolen time accounting (i.e.
>> cpustat->steal).
>>
>> I think what you want is to make sure that the sum of the cputime
>> passed to all of:
>>
>> account_user_time
>> account_system_time
>> account_steal_time
>>
>> adds up to the total amount of time that has passed. I think it is
>> sort of working for you (i.e. doesn't always double count stolen
>> ticks) since in NO_HZ mode, update_process_time (which calls
>> account_user_time & account_system_time) happens to be skipped during
>> periods of stolen time due to the hrtimer_forward()'ing of the one
>> shot expiry.
>
> OK, this will need a closer look.
>
> BTW, what are the properties of the vmi read_available_cycles()? Is
> that a per-cpu timer? If its used as the timebase for sched_clock, how
> does recalc_task_prio not get a -ve sleep time?
>
Available time is defined to be (real_time - stolen_time). i.e. time in
which the vcpu is either running or not ready to run [because it is
halted, and nothing is pending]).
So, yes, it is per-vcpu. But, the sched_clock() samples are rebased
when processes are migrated between runqueues; search sched.c for
most_recent_timestamp. It's not perfect since most_recent_timestamp
between cpu0 and cpu1 do not correspond to the exact same instant, but
does prevent negative sleep time and is fairly close.
Dan
next prev parent reply other threads:[~2007-03-15 19:09 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-13 16:31 Stolen and degraded time and schedulers Jeremy Fitzhardinge
2007-03-13 20:12 ` john stultz
2007-03-13 20:32 ` Jeremy Fitzhardinge
2007-03-13 21:27 ` Daniel Walker
2007-03-13 21:59 ` Jeremy Fitzhardinge
2007-03-14 0:43 ` Dan Hecht
2007-03-14 4:37 ` Jeremy Fitzhardinge
2007-03-14 13:58 ` Lennart Sorensen
2007-03-14 15:08 ` Jeremy Fitzhardinge
2007-03-14 15:12 ` Lennart Sorensen
2007-03-14 19:02 ` Dan Hecht
2007-03-14 19:34 ` Jeremy Fitzhardinge
2007-03-14 19:45 ` Rik van Riel
2007-03-14 19:47 ` Jeremy Fitzhardinge
2007-03-14 20:02 ` Rik van Riel
2007-03-14 20:26 ` Dan Hecht
2007-03-14 20:31 ` Jeremy Fitzhardinge
2007-03-14 20:46 ` Dan Hecht
2007-03-14 21:18 ` Jeremy Fitzhardinge
2007-03-15 19:09 ` Dan Hecht [this message]
2007-03-15 19:18 ` Jeremy Fitzhardinge
2007-03-15 19:48 ` Rik van Riel
2007-03-15 19:53 ` Jeremy Fitzhardinge
2007-03-15 20:07 ` Dan Hecht
2007-03-15 20:14 ` Rik van Riel
2007-03-15 20:35 ` Dan Hecht
2007-03-16 8:59 ` Martin Schwidefsky
2007-03-14 20:38 ` Ingo Molnar
2007-03-14 20:59 ` Jeremy Fitzhardinge
2007-03-16 8:38 ` Ingo Molnar
2007-03-16 16:53 ` Jeremy Fitzhardinge
2007-03-15 5:23 ` Paul Mackerras
2007-03-15 19:33 ` Jeremy Fitzhardinge
2007-03-14 2:00 ` Daniel Walker
2007-03-14 6:52 ` Jeremy Fitzhardinge
2007-03-14 8:20 ` Zan Lynx
2007-03-14 16:11 ` Daniel Walker
2007-03-14 16:37 ` Jeremy Fitzhardinge
2007-03-14 16:59 ` Daniel Walker
2007-03-14 17:08 ` Jeremy Fitzhardinge
2007-03-14 18:06 ` Daniel Walker
2007-03-14 18:41 ` Jeremy Fitzhardinge
2007-03-14 19:00 ` Daniel Walker
2007-03-14 19:44 ` Jeremy Fitzhardinge
2007-03-14 20:33 ` Daniel Walker
2007-03-14 21:16 ` Jeremy Fitzhardinge
2007-03-14 21:34 ` Daniel Walker
2007-03-14 21:42 ` Jeremy Fitzhardinge
2007-03-14 21:36 ` Con Kolivas
2007-03-14 21:38 ` Jeremy Fitzhardinge
2007-03-14 21:40 ` Con Kolivas
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=45F999D4.6080602@vmware.com \
--to=dhecht@vmware.com \
--cc=chrisw@sous-sol.org \
--cc=cpufreq@lists.linux.org.uk \
--cc=dwalker@mvista.com \
--cc=jeremy@goop.org \
--cc=johnstul@us.ibm.com \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@au.ibm.com \
--cc=riel@redhat.com \
--cc=schwidefsky@de.ibm.com \
--cc=tglx@linutronix.de \
--cc=virtualization@lists.osdl.org \
--cc=zach@vmware.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).