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: Fri, 20 Jun 2014 10:29:07 +0800 [thread overview]
Message-ID: <53A39C73.2070004@huawei.com> (raw)
In-Reply-To: <53A2A9BD.3070107@unitn.it>
On 2014/6/19 17:13, Luca Abeni wrote:
> On 06/18/2014 09:01 AM, xiaofeng.yan wrote:
> [...]
>>>>> 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.
> Ok, so I found my old code for the CBS scheduler with GRUB modifications.
> You can get it from here:
> http://disi.unitn.it/~abeni/old-cbs-scheduler.tgz
>
> Please note that:
> 1) This is old code (for 2.6.x kernels), written before SCHED_DEADLINE
> development
> was started
> 2) The scheduler architecture is completely different respect to the
> current one,
> but the basic scheduling algorithm implemented by my old scheduler
> is the same
> one implemented by SCHED_DEADLINE (but I did not implement
> multi-processor support :)
> 3) You can have a look at the modifications needed to implement GRUB
> by simply grepping
> for "GRUB" in the source code. Basically, the algorithm is
> implemented by:
> 1) Implementing a state machine to keep track of the current state
> of a task (is it
> using its reserved fraction of CPU time, did it already use such
> a fraction of CPU
> time, or is it not using any CPU time?). This is done by adding
> a "state" field in
> "cbs_struct", and properly updating it in cbs.c
> 2) Keeping track of the total fraction of CPU time used by the
> active tasks. See the "U"
> variable in cbs.c (in a modern scheduler, it should probably
> become a field in the
> runqueue structure)
> 3) Modifying the rule used to update the runtime. For a "standard"
> CBS without CPU
> reclaiming (the one implemented by SCHED_DEADLINE), if a task
> executes for an amount
> of time "delta" its runtime must be decreased by delta. For
> GRUB, it must be decreased
> by "delta" mutliplied by U. See "account()" in cbs.c.
> The "trick" is in properly updating U (and this is done using
> the state machine
> mentioned above)
>
> Summing up, this code is not directly usable, but it shows you what
> needs to be done in
> order to implement the GRUB mechanism for CPU reclaiming in a CBS
> scheduler...
>
>
Thanks for giving me your solution. I will take a look at it and modify
it in our scene later.
Thanks
Yan
>
> Luca
>
> .
>
prev parent reply other threads:[~2014-06-20 2:30 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
2014-06-19 9:13 ` Luca Abeni
2014-06-20 2:29 ` xiaofeng.yan [this message]
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=53A39C73.2070004@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.