On 18 March 2016 at 09:43, Sebastian Huber < sebastian.hu...@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.hu...@embedded-brains.de > > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > -- Thanking You, Darshit Shah
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
