All of lore.kernel.org
 help / color / mirror / Atom feed
From: "xiaofeng.yan" <xiaofeng.yan@huawei.com>
To: Luca Abeni <luca.abeni@unitn.it>
Cc: Henrik Austad <henrik@austad.us>,
	Juri Lelli <juri.lelli@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>, <duzhiping.du@huawei.com>,
	<xiaofeng.yan2012@gmail.com>, <raistlin@linux.it>,
	<tkhai@yandex.ru>, <harald.gustafsson@ericsson.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [RFD] sched/deadline: EDF dynamic quota design
Date: Wed, 18 Jun 2014 15:01:30 +0800	[thread overview]
Message-ID: <53A1394A.7040607@huawei.com> (raw)
In-Reply-To: <539FF5D2.9080703@unitn.it>

On 2014/6/17 16:01, Luca Abeni wrote:
> Hi,
>
> On 06/17/2014 04:43 AM, xiaofeng.yan wrote:
> [...]
>>> The basic ideas are (warning! This is an over-simplification of the 
>>> algorithm! :)
>>> - You assign runtime and period to each SCHED_DEADLINE task as usual
>>> - Each task is guaranteed to receive its runtime every period
>>> - You can also define a maximum fraction Umax of the CPU time that the
>>>   SCHED_DEADLINE tasks can use. Note that Umax _must_ be larger or 
>>> equal
>>>   than sum_i runtime_i / period_i
>>>   (note: in the original GRUB paper, only one CPU is considered, and 
>>> Umax is
>>>   set equal to 1)
>>> - If the tasks are consuming less than Umax, then the scheduling 
>>> algorithm
>>>   allows them to use more runtime (but not less than the guaranteed 
>>> runtime_i)
>>>   in order to use up to Umax.
>>>   This is achieved by modifying the rule used to decrease the 
>>> runtime: in
>>>   SCHED_DEADLINE, if a task executes for a time delta, its runtime 
>>> is decreased
>>>   by delta; using GRUB, it would be decreased by a smaller amount of 
>>> time
>>>   (computed based on Umax, on the active SCHED_DEADLINE tasks, etc...).
>>>   This requires to implement some kind of state machine (the details 
>>> are in
>>>   the GRUB paper)
>>>
>>> I also had an implementation of the GRUB algorithm (based on a 
>>> modification
>>> of my old CBS scheduler for Linux), but the computational complexity 
>>> of the
>>> algorithm was too high. That's why I never proposed to merge it in 
>>> SCHED_DEADLINE.
>>> But maybe there can be some trade-off between the "exact compliance 
>>> with the
>>> GRUB algorithm" and implementation efficiency that can make it 
>>> acceptable...
>>>
>>>
>> Has these  codes been opened about the implementation in some 
>> community or not ?
> The old GRUB scheduler for Linux was used for some experiments 
> published in a paper
> at RTLWS 2007, and of course the code was open-source (released under 
> GPL).
> It required a patch for the Linux kernel (I used a 2.6.something 
> kernel) which allowed
> to load the scheduler as a kernel module (yes, I know this is the 
> wrong way to go...
> But implementing it like this was simpler :).
> That is very old code... I probably still have it somewhere, but I 
> have to search
> for it. If someone is interested, I can try to search (the story of 
> the user-space
> daemon for adaptive reservations is similar: I released it as 
> open-source years ago...
> If anyone is interested I can search for this code too)
>
>
>                 Luca
>
I'm glad that you reply this email.  yes, I'm so interesting about your 
solution.  In fact , there are scenarios
in our product.  Could you send me a link if you have?  I can test your 
solution in our scene if you like.

Thanks
Yan
>



  reply	other threads:[~2014-06-18  7:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <537348DA.7080001@huawei.com>
     [not found] ` <20140514113245.GZ11096@twins.programming.kicks-ass.net>
2014-05-14 12:55   ` [RFD] sched/deadline: EDF dynamic quota design Peter Zijlstra
     [not found]   ` <53736CD9.90805@unitn.it>
     [not found]     ` <5374A335.90705@huawei.com>
2014-05-15 12:31       ` Juri Lelli
2014-05-16  7:11         ` Henrik Austad
2014-05-21 12:45           ` Luca Abeni
2014-06-17  2:43             ` xiaofeng.yan
2014-06-17  8:01               ` Luca Abeni
2014-06-18  7:01                 ` xiaofeng.yan [this message]
2014-06-19  9:13                   ` Luca Abeni
2014-06-20  2:29                     ` xiaofeng.yan

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=53A1394A.7040607@huawei.com \
    --to=xiaofeng.yan@huawei.com \
    --cc=duzhiping.du@huawei.com \
    --cc=harald.gustafsson@ericsson.com \
    --cc=henrik@austad.us \
    --cc=juri.lelli@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.abeni@unitn.it \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=raistlin@linux.it \
    --cc=tkhai@yandex.ru \
    --cc=xiaofeng.yan2012@gmail.com \
    /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.