From: Mike Galbraith <efault@gmx.de>
To: Venkatesh Pallipadi <venki@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org,
Ranjit Manomohan <ranjitm@google.com>
Subject: Re: [PATCH] sched: Buggy comparison in check_preempt_tick
Date: Sat, 25 Dec 2010 08:50:18 +0100 [thread overview]
Message-ID: <1293263418.6896.54.camel@marge.simson.net> (raw)
In-Reply-To: <1293236813-31550-1-git-send-email-venki@google.com>
On Fri, 2010-12-24 at 16:26 -0800, Venkatesh Pallipadi wrote:
> 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
Oops, that's a bug.
> * It compares runtime and vruntime, which breaks when there are niced tasks
This imho isn't.
vruntimes advance at different rates for differently weighted tasks, so
they're already weighted, as is ideal_runtime.
For wakeup preemption we use wakeup_gran() as the weighted ruler to
limit spread. This test just uses a different weighted ruler for the
same purpose at tick time, one already computed.
If you're a heavily niced task, you were very likely booted before you
got this far. If you haven't run for considerable wall time, you won't
get further, you keep on running. You only get booted if giving you a
full wall slice will spread vruntimes too much, for which you'll pay if
you keep running, and leftmost will pay now if we don't boot you.
-Mike
next prev parent reply other threads:[~2010-12-25 7:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-25 0:26 [PATCH] sched: Buggy comparison in check_preempt_tick Venkatesh Pallipadi
2010-12-25 7:50 ` Mike Galbraith [this message]
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=1293263418.6896.54.camel@marge.simson.net \
--to=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=ranjitm@google.com \
--cc=venki@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