Participation in GSoC 2016

[Darshit Shah]

On 18 March 2016 at 09:43, Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:
>
>
> On 16/03/16 22:11, Chris Johns wrote:
>>
>> On 16/03/2016 23:01, Darshit Shah wrote:
>>>
>>> I have updated my draft proposal with a basic timeline for things that
>>> need to be done. The link is shared on the tracking page and has been
>>> submitted via the program website as well. I'm sharing it here as well:
>>> https://goo.gl/UmgS61
>>>
>>> Since this is a draft proposal, it may not be completely polished yet.
>>> I'd appreciate any comments on it, especially the project description
>>> and timeline.
>>>
>
> " POSIX mandated processor affinityAPI"
>
> This is actually not defined in POSIX. Its a non-portable Linux/BSD
> extension.
>
That is true. I've fixed the documentation for this.

> "schedulable task sets would miss their deadlines since it does not
consider
> migrating high priority tasks"
>
> I think this is not correct. The current APA scheduler should implement
> strong APA. However, it may iterate several times over all (!) ready
tasks.
> This is the actual problem.
>
I may be wrong, but I think the current implementation does indeed not
consider strong APA guarantees.

The `_Scheduler_priority_affinity_SMP_Get_lowest_scheduled` method tries to
find a thread that needs to be migrated to another core in order to
schedule the selected thread. In this method, on line 274 is the comment:

>     /*
>      * If we didn't find a thread which is of equal or lower importance
>      * than filter thread is, then we can't schedule the filter thread
>      * to execute.
>      */
>
>
If I understand this comment correctly, the scheduler does not consider
threads for migration if they are not of "equal or lower importance" than
the filter thread.


> I would use the name "APA" for the new scheduler, e.g. schedulerapasmp.c.

I kept it as "priorityapa" based on the existing naming convention. How
about "Strong APA" to clearly state that this scheduler provides the Strong
APA guarantees?

>
> We already have a ticket for this work:
>
> https://devel.rtems.org/ticket/2510

Yes, I've looked at the ticket and referenced to it. I shall update the
draft to state that I will be using this ticket itself to discuss the ideas.

>
> With respect to the tests. In addition to worst case task sets, we have to
> define task sets that cover the basic operations and the corner cases. I
> suggest to use test driven development once the data structures and
> algorithm is clear. Start with a simple test and implement everything so
> that this test passes. Continue until everything is fine.
>
I agree. Though my understanding was that we already have test cases that
can be used to test any scheduler implementation. I'll add a section about
writing new test cases for the scheduler.
>>
>> Looking good.
>>
>> Could you please add something about the method of testing you plan to
>> use? Not the tests just the set up details, eg is this with the scheduler
>> simulator, qemu, or real hardware or all listed plus also which
>> architectures?
>
>
> We can use Qemu and the hardware here in our office.

That would be perfect. I can test via QEMU here while we can run some bare
metal tests at a later stage.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
>
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>



-- 
Thanking You,
Darshit Shah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160318/a8dc83e3/attachment-0001.html>