Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752725AbbDCR5t (ORCPT ); Fri, 3 Apr 2015 13:57:49 -0400 Received: from mail-la0-f42.google.com ([209.85.215.42]:36009 "EHLO mail-la0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750739AbbDCR5p (ORCPT ); Fri, 3 Apr 2015 13:57:45 -0400 Date: Fri, 3 Apr 2015 19:57:37 +0200 From: Henrik Austad To: Zhiqiang Zhang Cc: luca.abeni@unitn.it, juri.lelli@arm.com, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org Subject: Re: [PATCH] Documentation/scheduler/sched-deadline.txt: correct definition of density as C_i/min{D_i,P_i} Message-ID: <20150403175737.GA3847@icarus.home.austad.us> References: <1428049113-62546-1-git-send-email-zhangzhiqiang.zhang@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1428049113-62546-1-git-send-email-zhangzhiqiang.zhang@huawei.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2897 Lines: 72 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 > --- > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/