MSc (by research) involving RTEMS | University of York

Hesham Moustafa heshamelmatary at gmail.com
Mon Oct 27 20:43:18 UTC 2014


On Mon, Oct 27, 2014 at 2:30 PM, Joel Sherrill <joel.sherrill at oarcorp.com>
wrote:

>
>
> On October 27, 2014 3:04:26 AM PDT, Hesham Moustafa <
> heshamelmatary at gmail.com> wrote:
> >Hi all,
> >
> >
> >This year, I am studying MSc (by research) degree at the University of
> >York. My thesis proposal title is "REAL-TIME OPERATING SYSTEMS FOR
> >LARGE SCALE MANY-CORE NETWORK-ON-CHIP ARCHITECTURES." Part of this
> >research will include some work with RTEMS.
> >
>
> Awesome!
>
> There is an asymmetric MP patch filed with a PR in bugzilla. I don't
> remember the architecture but it was a proprietary CPU with virtually
> nothing useful publicly available. The company was Kalray and here is a
> link to one of their patches.
>
> http://lists.rtems.org/pipermail/bugs/2011-October/003376.html
>
> We merged some small stuff from them but they did not work in an open
> collaborative way with the community. They have a commercial product with a
> mesh of multi core instances. I suspect the key folks have published
> papers. Assuming that is vaguely related.
>
> How many is many? 16, 64,  etc.. Can you point to some example
> architectures?
>
> Given that I first met my supervisor today, I am currently on the stage of
collecting information, reading literature, and get sense of research work
that involves RTOS, so that we can choose which RTOS can fit on which
platform better, and of course that platform would have many cores. I asked
my supervisor this exact question, and he gave me two initial options (that
may change after readings): 1) Parallella board variants [1] that can
contain from 16 up to 64 cores (simple RISC processors) and 2) Bluestar
project that University of York research group currently works on, it has
64 cores and I may have the possibility to work on some NoC/SoC HW designs
part of my research.

>
> >That said, I'd appreciate any materials (papers, publications,
> >references, tutorials, etc) that might be of help regarding that topic
> >and may or may not relate to RTEMS. I think Sebastian has contributed a
> >lot to this area recently.
>
> Gedare and Sebastian are more in tune with the paper side of things.
>
> My suggestion is to divide it into areas. Of the top of my head, there are
> issues with algorithm scaling as the number of cores increases, locking
> issues, more need for finer grain locks and lockless data structures, and
> likely on the application side means to debug and formally make statements
> about WCET, end to end scheduling correctness in a way that is known to be
> analyzable for schedulability and correctness, and cache effects.
>
> Great, I'd like to get ideas of what challenges the current RTOSes like
RTEMS face regarding many-cores systems, and I think you are the best to
tell me somethings like that.

>
> RTEMS will face the same challenges Solaris, Linux etc faced as the number
> of cores grew beyond four. So there may be useful experience papers from
> those.
>
> >You may also want to suggest building some simple multi-processor
> >and/or many-core systems that RTEMS currently supports, and how to
> >simulate them.
>
> Tile may be interesting but you need to look. There should be 12-16 core
> qoriq ppc by now and qemu might be up to that.
> Maestro (I think) was a MIPS based SOC out of AFRL which might be
> interesting.
>
> But how many is "many" and me being at my desk will help. I just core
> dumped in an airport at 5am.
>
> What do you want the code to do?
>
> Initially, we want the code to fit in with many-cores platforms (16-64).
So, I am trying to see how far research goes regarding this area, and the
status of some SMP libraries/APIs that current RTOSes support, and start
from there.

[1] http://www.parallella.org/board/

> >
> >Thanks,
> >
> >Hesham
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20141027/a881a131/attachment-0002.html>


More information about the devel mailing list