linux-kernel - Re: [PATCH] Documentation/scheduler/sched-deadline.txt: correct definition of density as C_i/min{D_i,P

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20150403175737.GA3847@icarus.home.austad.us>
Date:	Fri, 3 Apr 2015 19:57:37 +0200
From:	Henrik Austad <henrik@...tad.us>
To:	Zhiqiang Zhang <zhangzhiqiang.zhang@...wei.com>
Cc:	luca.abeni@...tn.it, juri.lelli@....com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH] Documentation/scheduler/sched-deadline.txt: correct
 definition of density as C_i/min{D_i,P_i}

On Fri, Apr 03, 2015 at 04:18:33PM +0800, Zhiqiang Zhang wrote:
> From the contex,the definition of the destiny of a task

I'm sure we would all like to have a perfect scheduler, however, knowing 
the destiny of a task is a bit beyond what we can do now ;)

> C_i/min{D_i,T_i},where T_i is not referred before, should be
> substituted by C_i/min{D_i,P_i}.

Actually, I'd prefer we use T_i to describe the period and not P because:

- P is easy to confuse with priority - which has _nothing_ to do with 
  deadline scheduling

- I was going to state that "the litterature is consistent in its usage of 
  'T_i' for task i's period". But then I dived through some of the books 
  and of course it isn't. Buttazzo use T, Jane Liu use P and so on. 
  However, I state that *most* litterature use T_i do denote the period of 
  task i. Burns & Davis has a nice summary of RT-litterature [1].

So I'd rather prefer a s/P_i/T_i/ throughout the text.

I realise that I've reviewed quite a lot of this, and I have some vague 
memories of this being discussed earlier, Juri? Luca?


> ----------------------------------------
> 
> Signed-off-by: Zhiqiang Zhang <zhangzhiqiang.zhang@...wei.com>
> ---
>  Documentation/scheduler/sched-deadline.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/scheduler/sched-deadline.txt b/Documentation/scheduler/sched-deadline.txt
> index 21461a0..194664b 100644
> --- a/Documentation/scheduler/sched-deadline.txt
> +++ b/Documentation/scheduler/sched-deadline.txt
> @@ -169,8 +169,8 @@ CONTENTS
>   of all the tasks executing on a CPU if and only if the total utilisation
>   of the tasks running on such a CPU is smaller or equal than 1.
>   If D_i != P_i for some task, then it is possible to define the density of
> - a task as C_i/min{D_i,T_i}, and EDF is able to respect all the deadlines
> - of all the tasks running on a CPU if the sum sum_i C_i/min{D_i,T_i} of the
> + a task as C_i/min{D_i,P_i}, and EDF is able to respect all the deadlines
> + of all the tasks running on a CPU if the sum sum_i C_i/min{D_i,P_i} of the

My argument for T_i vs. P_i aside, I do agree that we should not use T_i 
here whilst using P_i in other places. We should strive to be internally 
consistent above all else.

So *if* we are going to use P_i for period, then this is correct and should 
be applied.

>   densities of the tasks running on such a CPU is smaller or equal than 1
>   (notice that this condition is only sufficient, and not necessary).
>  
> -- 
> 1.9.0
> 

Just my $0.02 etc etc :)


1) http://www-users.cs.york.ac.uk/~robdavis/papers/MPSurveyv5.0.pdf

-- 
Henrik Austad
--
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/