SuperCore Scheduler (GSOC 2014)

[Andre Marques]

Thanks for the responses.

What about thread processor affinity?

http://www.rtems.org/wiki/index.php/SMP#Processor_Affinity

I have seen Sebastian's opinion about it at

http://www.rtems.org/pipermail/rtems-devel/2014-February/005552.html

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 
POSIX.

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 
issues.

As a second step, continue the implementation and testing of Posix 
Asynchronous IO

http://www.rtems.org/wiki/index.php/POSIX_Asynchronous_IO

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).

Regards,
André Marques.

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:
>>> Hello,
>>>
>>> As stated in [1] I will be working with RTEMS for my undergraduate thesis,
>>> but
>>> 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()
>>> POSIX
>>> compliance. For GSOC, however, I would like to work on a SMP-aware
>>> scheduler,
>>> 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
>>> is
>>> 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.
>
> -Gedare
>
>>> 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
>> http://www.rtems.org/mailman/listinfo/rtems-devel
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel