SuperCore Scheduler (GSOC 2014)
andre.lousa.marques at gmail.com
Tue Mar 4 16:41:58 UTC 2014
Thanks for the responses.
What about thread processor affinity?
I have seen Sebastian's opinion about it at
but what is the current status?
What I understood is that there is a lot of work around SMP going on,
which is also leading to changes in the scheduler framework, making it
difficult to make a proposal on scheduling for GSOC, right?
Another alternative, and since I have been making a test to check
rename() POSIX compliance, I could make a proposal to do some work with
As a first step, making rename() POSIX compliant (thus continuing the
work I have been doing), and after that I could tackle some other POSIX
As a second step, continue the implementation and testing of Posix
which was a GSOC project in 2010, by Alin Rus. The project page seems
outdated, as only lio_listio () seems to be unimplemented at the moment.
What is the situation there?
More steps could be added if needed (or possible).
On 03/03/14 14:16, Gedare Bloom wrote:
> On Mon, Mar 3, 2014 at 2:21 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
>> On 2014-03-01 01:13, Andre Marques wrote:
>>> As stated in  I will be working with RTEMS for my undergraduate thesis,
>>> I'm also looking to work with RTEMS through GSOC.
>>> For the last month I have been working on a test case to check rename()
>>> compliance. For GSOC, however, I would like to work on a SMP-aware
>>> if possible.
>> Sorry, I still didn't have the time to review it.
>>> What I understood from the SuperCore Scheduler project page is that there
>>> still some work to be done on global edf started last year by Sree harsha
>>> konduri. Is it enough or relevant for another GSOC project?
> The solution Sree came out with is OK but I think needs to be improved
> in the future with fine-grained locks. We did not merge it because I
> am not confident it is ready to be used or maintained. Once the
> situation with SMP thread life cycle becomes more clear, we can start
> to add new schedulers. Until then, however, I am hesitant to encourage
> new SMP scheduler implementations to proceed.
>>> If not, would it be interesting to implement a new scheduler, for instance
>>> pfair or llref?
>> The SMP support is work in progress, so it is hard to predict how things
>> will turn out in the next couple of months. Gedare did a great job with the
>> scheduler operations API so that the scheduler is now an application
>> configuration option. One goal is to leverage it to support
>> clustered/partitioned scheduling. I think RTEMS will be a good platform to
>> study real-time SMP systems in the future. Currently a lot of research is
>> done on Linux. RTEMS however is much simpler to understand (e.g. no virtual
>> memory, much smaller code base) and may be a good experimental platform.
>> 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.
>> rtems-devel mailing list
>> rtems-devel at rtems.org
> rtems-devel mailing list
> rtems-devel at rtems.org
More information about the devel