SuperCore Scheduler (GSOC 2014)

[Andre Marques]

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
>