On 03/10, Gedare Bloom wrote:
@Joel, any thoughts / inputs on the state of the scheduling simulator would be very helpful. I'm currently trying to come up with a draft timeline for review, but this is a blocking factor. I've cloned the rtems-schedsim repository, but need some help / information on using it and what will need to be extended.Joel might answer about the state of the scheduling simulator.
I believe you eventually have to copy-paste your application into a form, so it is better if you stick to plain text. I don't even know if you can put images in. You may optionally link to a generated PDF, too. On Thu, Mar 10, 2016 at 6:13 AM, Darshit Shah <dar...@gmail.com> wrote:Hi, I've been a little busy with my semester end exams and other things recently. But I have spent time looking into the RTEMS Priority Scheduler with Processor Affinities and the paper mentioned in the trac ticket. At this point, I have a decent understanding of the paper and its algorithm and am looking into how we may implement it in RTEMS. To this end, I am looking for help / guidance.This would be a good project. I would add a few steps to simply implementing it. + Update the scheduling simulator since it is a lot easier to test using that. It is also easier to ensure you keep the same behavior.This sounds like it would be in important part of the implementation of the paper. However, I do not know anything about the existing scheduling simulator. Any links to this and basic pointers on how I should go about extending it would be a great start. I'll incorporate this into my draft proposal as soon as I have a better idea of what needs to be done.+ Propose criteria for knowing if the new algorithm is really better for RTEMS than the old one. Evaluating algorithms for RTEMS use involves big-O of the algorithm, data space requirements (and big-O of that), global knowledge required, and maybe other factors.The new algorithm is almost definitely worse in time and space than the existing algorithm. Based on a preliminary analysis, it will be able to use the existing Priority Affinity Scheduler for the most part and add a O(|E|) complexity to each thread blocking and unblocking operation. Here, E is the set of all processor affinity assignments, so it will approximately add an extra linear increase in scheduling overhead w.r.t. the number of processes that use this scheduler. I haven't specifically looked into the space requirements, but it will be worse than the existing scheduler. However, the point to realize is that after these changes, more user programs that set processor affinities will be able to meet their deadlines as compared to the existing scheduler. This should happen despite the higher scheduling overheads.+ Testing on scheduling simulator and in RTEMS testsuite to ensure it is functionally identical to the current algorithm.Once again, some pointers tot he scheduling simulator would help me a lot.If the algorithm is functionally identical to the current one and superior in execution time/data requirements, then replacing it is a no brainer. If there are trade-offs on when one is better than the other in real life, then we will all have to characterize those.I was thinking more along the lines of writing a new scheduler instead of replacing the existing one. A PriorityStringAPA scheduler that pretty much reuses all the existing priority affinity scheduler code apart from the two operations. This is because, with some task sets where the affinity assignments are not too restrictive, the lower overheads of the existing scheduler may be preferred over the new one. I have also been writing my draft proposal for GSoC. A version is currently available on GDrive and a link has been put on on the student tracking page. However, I wanted to ask if sharing a PDF of the proposal would be possible. Since, I would be more comfortable in making the entire proposal in Latex and sharing the final PDF. If not, I can keep working on the proposal in Google Docs. -- Thanking You, Darshit Shah
-- Thanking You, Darshit Shah
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
