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.marq...@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.hu...@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.hu...@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@rtems.org >>>> http://www.rtems.org/mailman/listinfo/rtems-devel >>> >>> _______________________________________________ >>> rtems-devel mailing list >>> rtems-devel@rtems.org >>> http://www.rtems.org/mailman/listinfo/rtems-devel >> >> > _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
