From: Ingo Molnar <mingo@elte.hu>
To: Ting Yang <tingy@cs.umass.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] CFS scheduler, -v7
Date: Thu, 3 May 2007 17:17:41 +0200 [thread overview]
Message-ID: <20070503151741.GC1812@elte.hu> (raw)
In-Reply-To: <4639F970.5080701@cs.umass.edu>
* Ting Yang <tingy@cs.umass.edu> wrote:
> + s64 __delta = curr->fair_key - p->fair_key;
> +
> + /*
> + * Take scheduling granularity into account - do not
> + * preempt the current task unless the best task has
> + * a larger than sched_granularity fairness advantage:
> + */
> + if (__delta > niced_granularity(rq, curr, granularity))
> + resched_task(curr);
> +}
>
> This code actually now says, the difference of fair_key needed to
> preempt the current task is amplified by a facto of its weigh (in Al
> Boldi's example 32). However, the weighted task already advance its
> p->fair_key by its weight, (also 32 here). The combination of them
> becomes quadratic!
it's not quadratic in terms of CPU share: the first factor impacts the
CPU share, the second factor impacts the granularity. This means that
reniced workloads will be preempted in a more finegrained way - but
otherwise there's _no_ quadratic effect for CPU time - which is a
completely separate metric. Remember: there are no timeslices in CFS, so
a task can be preempted any number of times without being at a
disadvantage.
> Besides this quadratic effect, another minor issue amplified this
> a little bit further: p->wait_runtime accumulated before. [...]
actually, this 'minor issue' was the main issue that caused the bug ;-)
Ingo
next prev parent reply other threads:[~2007-05-03 15:17 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-30 5:20 [patch] CFS scheduler, -v7 Al Boldi
2007-05-03 7:45 ` Ingo Molnar
2007-05-03 8:07 ` Ingo Molnar
2007-05-03 11:16 ` Al Boldi
2007-05-03 12:36 ` Ingo Molnar
2007-05-03 13:49 ` Al Boldi
2007-05-03 8:42 ` Al Boldi
2007-05-03 15:02 ` Ting Yang
2007-05-03 15:17 ` Ingo Molnar [this message]
2007-05-03 16:00 ` Ting Yang
2007-05-03 19:48 ` Ingo Molnar
2007-05-03 19:57 ` William Lee Irwin III
-- strict thread matches above, loose matches on Subject: below --
2007-04-28 15:25 Ingo Molnar
2007-04-28 19:20 ` S.Çağlar Onur
2007-04-28 19:24 ` Ingo Molnar
2007-04-28 23:42 ` S.Çağlar Onur
2007-04-29 7:11 ` Ingo Molnar
2007-04-29 12:37 ` S.Çağlar Onur
2007-04-29 15:58 ` Ingo Molnar
2007-04-29 22:29 ` Dennis Brendel
2007-04-30 14:38 ` S.Çağlar Onur
2007-04-28 19:27 ` S.Çağlar Onur
2007-04-29 17:28 ` Prakash Punnoor
2007-05-04 13:05 ` Prakash Punnoor
2007-04-30 16:29 ` Srivatsa Vaddagiri
2007-04-30 18:30 ` Balbir Singh
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=20070503151741.GC1812@elte.hu \
--to=mingo@elte.hu \
--cc=linux-kernel@vger.kernel.org \
--cc=tingy@cs.umass.edu \
/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.