Participation in GSoC 2016
darnir at gmail.com
Fri Mar 18 13:38:54 UTC 2016
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:
>>> 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
That is true. I've fixed the documentation for this.
> "schedulable task sets would miss their deadlines since it does not
> 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
> 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
> We already have a ticket for this work:
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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel