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
