From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: J K Rai <jk.anurag@yahoo.com>
Cc: Ingo Molnar <mingo@elte.hu>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: Time slice for SCHED_BATCH ( CFS)
Date: Thu, 12 Feb 2009 10:13:31 +0100 [thread overview]
Message-ID: <1234430011.23438.200.camel@twins> (raw)
In-Reply-To: <441046.97200.qm@web94712.mail.in2.yahoo.com>
On Thu, 2009-02-12 at 11:17 +0530, J K Rai wrote:
>
> May I have little more clarification on this:
>
> latency := 20ms * (1 + log2(nr_cpus))
> min_granularity := 4ms * (1 + log2(nr_cpus))
> nr_latency := floor(latency / min_granularity)
>
> 1) In above the 20ms and 4 ms seems to be the default values of
> sched_latency_ns and sched_min_granularity_ns, that means if we change
> them thru sysctl -w then we should keep those changed values in the
> above relationship in place of 20ms and 4 ms. Am I correct?
Yes, sysctl setting replaces the whole expression, that is, including
the log2 cpu factor.
> 2) What exactly or tentatively we signify by latency, min_granularity
> and nr_latency?
latency -- the desired scheduling latency of applications on low/medium
load machines (20ms is around the human observable).
min_granularity -- since we let slices get smaller the more tasks there
are in roughly: latency/nr_running fashion, we want to avoid them
getting too small. min_granularity provides a lower bound.
nr_latency -- the cut off point where we let go of the desired
scheduling latency and start growing linearly.
> latency ; nr_running <= nr_latency
> period = {
> nr_running * min_granularity ; nr_running > nr_latency
>
> slice = task_weight * period / runqueue_weight
>
>
> 3) Here in above, what is meant by task_weight and runqueue_weight ?
Since CFS is a proportional weight scheduler, each task is assigned a
relative weight. Two tasks with weight 1 will get similar amounts of cpu
time, a weight ratio of 1:2 will get the former task half as much cpu
time as the latter.
The runqueue weight is the sum of all task weights.
> Load-balancing of course makes this an even more interesting thing.
>
> 4) Can we say something more about load-balancing effect on
> time-slice.
> How the load-balancing works at present, is it by making the trees of
> equal hight / no of elements?
Well, load balancing just moves tasks around trying to ensure the sum of
weights on each cpu is roughly equal, the slice calculation is done with
whatever is present on a single cpu.
next prev parent reply other threads:[~2009-02-12 9:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <315626.71453.qm@web94713.mail.in2.yahoo.com>
[not found] ` <20090211102024.GI20518@elte.hu>
[not found] ` <1234348436.23438.119.camel@twins>
[not found] ` <303179.28635.qm@web94707.mail.in2.yahoo.com>
2009-02-11 12:40 ` Ingo Molnar
2009-02-11 13:02 ` Peter Zijlstra
[not found] ` <441046.97200.qm@web94712.mail.in2.yahoo.com>
2009-02-12 9:13 ` Peter Zijlstra [this message]
[not found] ` <466094.58460.qm@web94704.mail.in2.yahoo.com>
2009-02-12 11:04 ` Peter Zijlstra
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=1234430011.23438.200.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=jk.anurag@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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
all inboxes | Powered by JetHome®