linux-kernel - Re: Time slice for SCHED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <1234430011.23438.200.camel@twins>
Date:	Thu, 12 Feb 2009 10:13:31 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	J K Rai <jk.anurag@...oo.com>
Cc:	Ingo Molnar <mingo@...e.hu>, lkml <linux-kernel@...r.kernel.org>
Subject: Re: Time slice for SCHED_BATCH ( CFS)

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/