public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Paul Turner <pjt@google.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Mike Galbraith <efault@gmx.de>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [patch 2/2] sched: charge unaccounted run-time on entity re-weight
Date: Thu, 16 Dec 2010 12:03:44 +0100	[thread overview]
Message-ID: <1292497424.6803.4573.camel@twins> (raw)
In-Reply-To: <20101216031038.159704378@google.com>

On Wed, 2010-12-15 at 19:10 -0800, Paul Turner wrote:
> plain text document attachment (update_on_reweight.patch)
> Mike Galbraith reported poor interactivity[*] when the new shares distribution 
> code was combined with autogroups.
> 
> The root cause turns out to be a mis-ordering of accounting accrued execution
> time and shares updates.  Since update_curr() is issued hierarchically,
> updating the parent entity weights to reflect child enqueue/dequeue results in
> the parent's unaccounted execution time then being accrued (vs vruntime) at the
> new weight as opposed to the weight present at accumulation.
> 
> While this doesn't have much effect on processes with timeslices that cross a
> tick, it is particularly problematic for an interactive process (e.g. Xorg)
> which incurs many (tiny) timeslices.  In this scenario almost all updates are
> at dequeue which can result in significant fairness perturbation (especially if
> it is the only thread, resulting in potential {tg->shares, MIN_SHARES}
> transitions).
> 
> Correct this by ensuring unaccounted time is accumulated prior to manipulating
> an entity's weight.
> 
> [*] http://xkcd.com/619/ is perversely Nostradamian here.
> 
> Signed-off-by: Paul Turner <pjt@google.com>
> 
> ---
>  kernel/sched_fair.c |    6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> Index: tip3/kernel/sched_fair.c
> ===================================================================
> --- tip3.orig/kernel/sched_fair.c
> +++ tip3/kernel/sched_fair.c
> @@ -767,8 +767,12 @@ static void update_cfs_load(struct cfs_r
>  static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
>  			    unsigned long weight)
>  {
> -	if (se->on_rq)
> +	if (se->on_rq) {
> +		/* commit outstanding execution time */
> +		if (cfs_rq->curr == se)
> +			update_curr(cfs_rq);
>  		account_entity_dequeue(cfs_rq, se);
> +	}
>  
>  	update_load_set(&se->load, weight);
>  

Hrmm,. so we have:

entity_tick()
  update_curr()
  update_entity_shares_tick()
    update_cfs_shares()
      reweight_entity()


{en,de}queue_entity()
  update_curr()
  update_cfs_shares()
    reweight_entity()

{en,de}queue_task_fair()
  update_cfs_shares() (the other branch)

update_shares_cpu()
  update_cfs_shares()

So wouldn't something like the below be nicer?

---

Index: linux-2.6/kernel/sched_fair.c
===================================================================
--- linux-2.6.orig/kernel/sched_fair.c
+++ linux-2.6/kernel/sched_fair.c
@@ -1249,6 +1249,7 @@ enqueue_task_fair(struct rq *rq, struct
 	for_each_sched_entity(se) {
 		struct cfs_rq *cfs_rq = cfs_rq_of(se);
 
+		update_curr(cfs_rq);
 		update_cfs_load(cfs_rq, 0);
 		update_cfs_shares(cfs_rq, 0);
 	}
@@ -1279,6 +1280,7 @@ static void dequeue_task_fair(struct rq
 	for_each_sched_entity(se) {
 		struct cfs_rq *cfs_rq = cfs_rq_of(se);
 
+		update_curr(cfs_rq);
 		update_cfs_load(cfs_rq, 0);
 		update_cfs_shares(cfs_rq, 0);
 	}
@@ -2085,6 +2087,7 @@ static int update_shares_cpu(struct task
 	raw_spin_lock_irqsave(&rq->lock, flags);
 
 	update_rq_clock(rq);
+	update_curr(cfs_rq);
 	update_cfs_load(cfs_rq, 1);
 
 	/*



  parent reply	other threads:[~2010-12-16 11:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-16  3:10 [patch 0/2] Fix interactivity buglet with autogroup and shares distribution re-write Paul Turner
2010-12-16  3:10 ` [patch 1/2] sched: move periodic share updates to entity_tick() Paul Turner
2010-12-16 11:03   ` Peter Zijlstra
2010-12-16 14:26     ` Mike Galbraith
2011-01-10 23:49       ` Paul Turner
2011-01-11  0:47         ` Paul Turner
2010-12-20  8:36   ` [tip:sched/core] sched: Move " tip-bot for Paul Turner
2010-12-16  3:10 ` [patch 2/2] sched: charge unaccounted run-time on entity re-weight Paul Turner
2010-12-16  3:35   ` Paul Turner
2010-12-16  3:36     ` Paul Turner
2010-12-16  3:38     ` Paul Turner
2010-12-16 11:03   ` Peter Zijlstra [this message]
2010-12-16 22:31     ` Paul Turner
2010-12-17 12:38       ` Peter Zijlstra
2010-12-20  8:37   ` [tip:sched/core] sched: Fix interactivity bug by charging " tip-bot for Paul Turner

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=1292497424.6803.4573.camel@twins \
    --to=a.p.zijlstra@chello.nl \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pjt@google.com \
    --cc=torvalds@linux-foundation.org \
    /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