public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Venkatesh Pallipadi <venki@google.com>
To: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org,
	Ranjit Manomohan <ranjitm@google.com>,
	Venkatesh Pallipadi <venki@google.com>
Subject: [PATCH] sched: Buggy comparison in check_preempt_tick
Date: Fri, 24 Dec 2010 16:26:53 -0800	[thread overview]
Message-ID: <1293236813-31550-1-git-send-email-venki@google.com> (raw)

A preempt comparison line in check_preempt_tick has two bugs.
* It compares signed and unsigned quantities, which breaks when signed
  quantity happens to be negative
* It compares runtime and vruntime, which breaks when there are niced tasks

The bug was initially found by linsched[1]. Change here fixes both
the problems.

On x86-64, the signed unsigned compare results in tasks running _longer_
than their expected time slice as a false resched_task() gets signalled after
4 ticks (on tick after preceding sysctl_sched_min_granularity check) and
currently running task gets picked again and runs for another ideal_slice
interval.

With 2 busy loops on a single CPU and trace_printks inside this buggy check
triggering resched task and in pick_next_task shows this:

 [001]   510.524336: pick_next_task_fair: loop (5939)
 [001]   510.536326: pick_next_task_fair: loop (5883)
 [001]   510.540319: task_tick_fair: delta -4897059, ideal_runtime 11994146
 [001]   510.540321: pick_next_task_fair: loop (5883)
 [001]   510.544306: task_tick_fair: delta -906540, ideal_runtime 11994146
 [001]   510.544309: pick_next_task_fair: loop (5883)
 [001]   510.556306: pick_next_task_fair: loop (5939)
 [001]   510.560301: task_tick_fair: delta -7105824, ideal_runtime 11994146
 [001]   510.560304: pick_next_task_fair: loop (5939)
 [001]   510.564298: task_tick_fair: delta -3105461, ideal_runtime 11994146
 [001]   510.564300: pick_next_task_fair: loop (5939)
 [001]   510.576288: pick_next_task_fair: loop (5883)
 [001]   510.580282: task_tick_fair: delta -4897210, ideal_runtime 11994146
 [001]   510.580285: pick_next_task_fair: loop (5883)
 [001]   510.584278: task_tick_fair: delta -897348, ideal_runtime 11994146
 [001]   510.584281: pick_next_task_fair: loop (5883)
 [001]   510.596269: pick_next_task_fair: loop (5939)

That is 20 ms slice for each task, with some redundant resched_tasks and
with the fix it is expected ~12ms slices (on 16 cpu system).

[1] - http://lwn.net/Articles/409680/

Signed-off-by: Venkatesh Pallipadi <venki@google.com>
---
 kernel/sched_fair.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index 00ebd76..fc5ffbd 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -871,8 +871,10 @@ check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr)
 	if (cfs_rq->nr_running > 1) {
 		struct sched_entity *se = __pick_next_entity(cfs_rq);
 		s64 delta = curr->vruntime - se->vruntime;
+		unsigned long ideal_vruntime;
 
-		if (delta > ideal_runtime)
+		ideal_vruntime = calc_delta_fair(ideal_runtime, curr);
+		if (delta > (s64)ideal_vruntime)
 			resched_task(rq_of(cfs_rq)->curr);
 	}
 }
-- 
1.7.3.1


             reply	other threads:[~2010-12-25  0:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-25  0:26 Venkatesh Pallipadi [this message]
2010-12-25  7:50 ` [PATCH] sched: Buggy comparison in check_preempt_tick Mike Galbraith
2010-12-26  0:05   ` Venkatesh Pallipadi
2010-12-26  7:23     ` Mike Galbraith
2010-12-28  5:48       ` Mike Galbraith
2011-01-05  4:41         ` [PATCH] " Mike Galbraith
2011-01-18 19:06           ` [tip:sched/urgent] sched: Fix signed unsigned comparison in check_preempt_tick() tip-bot for Mike Galbraith

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=1293236813-31550-1-git-send-email-venki@google.com \
    --to=venki@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=ranjitm@google.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