public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Chris Friesen <cbf123@mail.usask.ca>,
	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, 5 Mar 2016 14:19:00 +0100	[thread overview]
Message-ID: <20160305131856.GA4441@lerouge> (raw)
In-Reply-To: <alpine.DEB.2.11.1603051121550.3686@nanos>

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.
>      
> > The fix is to change steal_account_process_tick() to always return
> > jiffies.  If CONFIG_VIRT_CPU_ACCOUNTING_GEN is not enabled then this
> > is a no-op.
> 
> What does that fix? 
>  
> > As far as I can tell this bug has been present since commit dee08a72.
> 
> Which bug?
> 
> > Signed-off-by: Chris Friesen <chris.friesen@windriver.com>
> > ---
> > 
> >  kernel/sched/cputime.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> > index b2ab2ff..e724496 100644
> > --- a/kernel/sched/cputime.c
> > +++ b/kernel/sched/cputime.c
> > @@ -276,7 +276,7 @@ static __always_inline bool steal_account_process_tick(void)
> >  		this_rq()->prev_steal_time += cputime_to_nsecs(steal_ct);
> >  
> >  		account_steal_time(steal_ct);
> > -		return steal_ct;
> > +		return cputime_to_jiffies(steal_ct);
> 
> So if steal time is close to a jiffie, then cputime_to_jiffies will return 0
> and you account a full jiffie to user/system/whatever.
> 
> Without a proper explanation of the problem and the resulting "bug" I really
> cannot figure out why we want that change.

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.

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. 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-05 13:19 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 [this message]
2016-03-06  4:17     ` Chris Friesen
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=20160305131856.GA4441@lerouge \
    --to=fweisbec@gmail.com \
    --cc=cbf123@mail.usask.ca \
    --cc=daniel.lezcano@linaro.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox