All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Friesen <cbf123@mail.usask.ca>
To: Frederic Weisbecker <fweisbec@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>, Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH] steal_account_process_tick() should return jiffies
Date: Sat, 05 Mar 2016 22:17:49 -0600	[thread overview]
Message-ID: <56DBAF6D.5010503@mail.usask.ca> (raw)
In-Reply-To: <20160305131856.GA4441@lerouge>

On 03/05/2016 07:19 AM, Frederic Weisbecker wrote:
> On Sat, Mar 05, 2016 at 11:27:01AM +0100, Thomas Gleixner wrote:
>> Chris,
>>
>> On Fri, 4 Mar 2016, Chris Friesen wrote:
>>
>> First of all the subject line should contain a subsystem prefix,
>> i.e. "sched/cputime:"
>>
>>> The callers of steal_account_process_tick() expect it to return whether
>>> the last jiffy was stolen or not.
>>>
>>> Currently the return value of steal_account_process_tick() is in units
>>> of cputime, which vary between either jiffies or nsecs depending on
>>> CONFIG_VIRT_CPU_ACCOUNTING_GEN.
>>
>> Sure, but what is the actual problem? The return value is boolean and tells
>> whether there was stolen time accounted or not.

> Indeed the changelog should better explain the problem. So I think the issue is that
> if the cputime has nsecs granularity and we have a tiny stolen time to account (lets say
> a few nanosecs, in fact anything that is below a jiffy), we are not going to account the
> tick on user/system.

Yes, this is exactly it.  Because of this, if CONFIG_VIRT_CPU_ACCOUNTING_GEN is 
enabled in a guest then the idle/system/user stats in /proc/stat can show odd 
values, and "top" shows nothing for user/system even if CPU hogs are running.

> But the fix doesn't look right to me because we are still accounting the steal time
> if it is lower than a jiffy and that steal time will never be substracted to user/system
> time if it never reach a jiffy.
>
> Instead the fix should accumulate the steal time and account it only once it's worth
> a jiffy and then substract it from system/user time accordingly.

Yes, on reflection you are correct, and the patch looks pretty close, except 
that account_steal_time() is still expecting units of cputime.  I'll send a 
followup patch.

 > Something like that:
>
> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> index b2ab2ff..d38e25f 100644
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -262,7 +262,7 @@ static __always_inline bool steal_account_process_tick(void)
>   #ifdef CONFIG_PARAVIRT
>   	if (static_key_false(&paravirt_steal_enabled)) {
>   		u64 steal;
> -		cputime_t steal_ct;
> +		unsigned long steal_jiffies;
>
>   		steal = paravirt_steal_clock(smp_processor_id());
>   		steal -= this_rq()->prev_steal_time;
> @@ -272,11 +272,11 @@ static __always_inline bool steal_account_process_tick(void)
>   		 * based on jiffies). Lets cast the result to cputime
>   		 * granularity and account the rest on the next rounds.
>   		 */
> -		steal_ct = nsecs_to_cputime(steal);
> -		this_rq()->prev_steal_time += cputime_to_nsecs(steal_ct);
> +		steal_jiffies = nsecs_to_jiffies(steal);
> +		this_rq()->prev_steal_time += jiffies_to_nsecs(steal_jiffies);
>
>   		account_steal_time(steal_ct);
> -		return steal_ct;
> +		return steal_jiffies;
>   	}
>   #endif
>   	return false;
>

  reply	other threads:[~2016-03-06  4:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-04 22:59 [PATCH] steal_account_process_tick() should return jiffies Chris Friesen
2016-03-05 10:27 ` Thomas Gleixner
2016-03-05 13:19   ` Frederic Weisbecker
2016-03-06  4:17     ` Chris Friesen [this message]
2016-03-06  5:18       ` [PATCH v2] sched/cputime: " Chris Friesen
2016-03-06 10:58         ` Thomas Gleixner
2016-03-08 12:29         ` Frederic Weisbecker
2016-03-08 13:18         ` [tip:sched/core] sched/cputime: Fix steal_account_process_tick() to always " tip-bot for Chris Friesen

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=56DBAF6D.5010503@mail.usask.ca \
    --to=cbf123@mail.usask.ca \
    --cc=daniel.lezcano@linaro.org \
    --cc=fweisbec@gmail.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.