SuperCore Scheduler (GSOC 2014)

Sun Mar 9 17:51:20 UTC 2014

Thank you for the reply.

On 03/09/14 01:23, Gedare Bloom wrote:
> I don't think there is enough lead time to develop a good project
> proposal about "Scheduling arbitrary resources". That project idea is
> still half-cooked.
>
> There are quite a few small projects that are all related to SMP that
> might be possible to put together into a single project proposal. Some
> of these include: replacing task variable uses, then disabling them
> for SMP,

 From what I saw of task variables implementation 
(cpukit/rtems/src/taskvariable*) it gives a not implemented error when 
called from a SMP system. So aren't they already disabled for SMP? In 
the SMP wiki page requirements list, on classic API, it says that "Usage 
of task variables shall lead to a compile time error. ", so the not 
implemented error should be replaced by static assertion (at compile 
time)? The same goes for task non-preempt mode (changing the run-time 
error to compile-time).

  The alternatives for task variables for SMP (thread-local storage and 
POSIX keys) already seem to have some work done, so I suppose someone is 
working on them now?

> adjusting tests for features not in SMP, ensuring code using
> features not in SMP breaks early and with a consistently useful
> failure, and work on any features on the list at the SMP wiki page
> that are not being developed by anyone else.
> -Gedare

The problem is everything in the SMP task list seems to be already under 
way. Maybe it would be better for me to focus outside SMP for GSoC.

For POSIX I could:

- Continue rename() test case (including the issues I have postponed 
until now) and then make rename() POSIX conformant
- Implement lio_listio() (the only function that seems unimplemented at 
http://www.rtems.org/wiki/index.php/POSIX_Asynchronous_IO)
- Test POSIX FIFOS (http://www.rtems.org/wiki/index.php/POSIXFIFOs)
- Solve some issues with newlib 
(http://www.rtems.org/wiki/index.php/POSIX_Methods_in_NewLib_RTEMS_improvements)

What do you think?

--Andre Marques.

> On Sat, Mar 8, 2014 at 1:38 PM, Andre Marques
> <andre.lousa.marques at gmail.com> wrote:
>> Hello,
>>
>> what about the project "Scheduling arbitrary resources"? Would it be
>> possible for GSoC? I'm not aware of the specific details involved yet, but I
>> could do some research if it is.
>>
>> I have a rough idea of how the sheduler framework works for threads (tasks),
>> but not for other entities.
>>
>> Thank you for your time.
>>
>> --Andre Marques.
>>
>>
>> On 03/04/14 16:41, Andre Marques wrote:
>>> 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
>>>