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