EDF Pluggable Scheduler

Mon Apr 4 18:19:10 UTC 2011

On 04/04/2011 12:14 PM, Petr Benes wrote:
> Hi,
>
> Thank you for the reply, it looks that for the best convenience matching
> to the current pluggable scheduler framework your advice regarding the
> Scheduler_Update is reasonable and instinctive.
>
Gedare's refactoring reflected the current state of the code
with respect to one scheduling algorithm implemented.
It is always possible that the concept needs tinkering or
extending to handle alternative scheduling concepts.

I am (slowly) continuing to work on SMP support for RTEMS
and this will require an SMP aware scheduler.  Hopefully we
will spot what areas the framework is weak and can address
those.
> However, I have just one more question. If we consider deadlines as
> current_priority, which is an uint32 type, since the deadline is a
> continuously increasing time, the current_priority overflows sooner or
> later. That is not a problem for the deadline comparison, I can handle
> it, but starts to matter as far as the Priority Inheritance Protocol is
> concerned. It does not know that a later deadline may be represented by
> a lower (overflown) number.
>
> How do you look upon this issue? Would be a solution to have another
> pluggable function implementing a priority comparison operation? Is this
> just a short-sighted point of view of EDF?
>
A scheduler plugin can allocate memory per task/thread.  You
could use this to store whatever you wish.

I have wondered if it makes sense to add an API call to give
extra information to the scheduler.  But so far, this hasn't
been a need.

Your work is one of the reasons I wanted a pluggable framework.
Let's try to make it work. :-D
> Kind regards
>
> Petr
>
>
>
> On 03/31/2011 09:15 PM, Gedare Bloom wrote:
>> Hi Petr,
>>
>> This is an interesting project. I did not concern myself with
>> synchronization issues, so I did not implement anything to deal with
>> deadilne interchange. With the pluggable scheduler framework, it
>> should be sufficient to implement Scheduler_Update -- I don't know if
>> enough information is passed currently, you may need to ensure that
>> current_priority always represents the thread's deadline.
>>
>> I consider this a failing of the tight integration of threads and
>> priority values. I tried to refactor this priority handling into a
>> separate Priority Handler, but it was hard to separate the priority
>> logic and still have efficient thread management.  It might be
>> worthwhile to reconsider this in light of the need to handle priority
>> in an opaque way in the mutex code.
>>
>> There was another edf implementation done (
>> http://code.google.com/p/rtems-edf/ ) that is based on Martin's work
>> as well. It was implemented before the pluggable interface.
>>
>> I have not revised my EDF to fit the current pluggable framework (it
>> is close, but some variations), as I am waiting on the merge of the
>> red-black tree (https://www.rtems.org/bugzilla/show_bug.cgi?id=1641).
>>
>> Good luck, and feel free to contact me for more details/assistance.
>> Gedare
>>
>> On Thu, Mar 31, 2011 at 6:59 AM, Petr Benes<benesp16 at fel.cvut.cz>   wrote:
>>> Dear Mr. Bloom,
>>>
>>> I am applying to you for an advice regarding RTEMS scheduling.
>>>
>>> I am currently working on my master thesis at CTU Prague dealing with
>>> porting a resource reservation framework (www.frescor.org) onto RTEMS. I
>>> need to ensure a temporal independence/isolation of separate tasks and for
>>> this we are to use an EDF scheduler with an incorporated CBS (Constant
>>> Bandwidth Server).
>>>
>>> As far as I am concerned, you work on some EDF or you have it done. I assume
>>> it is a pluggable one, since there is the feature in RTEMS 4.11 already
>>> implemented.
>>>
>>> I have just finished a quickie implementation of a pluggable EDF on my own
>>> (git at rtime.felk.cvut.cz:/rtems-pluggable-edf) having Martin Molnar's one as
>>> an example. I guess you know each other (he is also from CTU).
>>>
>>> The question I have is whether you happen to have some solution or at least
>>> an idea how to handle Deadline interchange and you are willing to share the
>>> experience. There is nothing reasonable proposed in the thesis by Martin
>>> Molnar (https://dip.felk.cvut.cz/browse/pdfcache/molnam1_2006dipl.pdf). So
>>> far, for sake of simplicity, I was thinking about some kind of hack making
>>> use of the current RAPs used by priority scheduling.
>>>
>>> Best regards
>>>
>>> Bc. Petr Beneš
>>> --------------------------
>>> mail  : benesp16 at fel.cvut.cz
>>> web   : www.petben.net
>>> mobile: +420 774 990 750
>>> icq   : 286131561
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>
>

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985