SuperCore Scheduler (GSOC 2014)

Sun Mar 9 01:23:46 UTC 2014

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, 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

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