<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 28, 2014 at 6:06 AM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@gwmail.gwu.edu" target="_blank">gedare@gwmail.gwu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Oct 27, 2014 at 4:43 PM, Hesham Moustafa<br>
<<a href="mailto:heshamelmatary@gmail.com">heshamelmatary@gmail.com</a>> wrote:<br>
><br>
><br>
> On Mon, Oct 27, 2014 at 2:30 PM, Joel Sherrill <<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>><br>
> wrote:<br>
>><br>
>><br>
>><br>
>> On October 27, 2014 3:04:26 AM PDT, Hesham Moustafa<br>
>> <<a href="mailto:heshamelmatary@gmail.com">heshamelmatary@gmail.com</a>> wrote:<br>
>> >Hi all,<br>
>> ><br>
>> ><br>
>> >This year, I am studying MSc (by research) degree at the University of<br>
>> >York. My thesis proposal title is "REAL-TIME OPERATING SYSTEMS FOR<br>
>> >LARGE SCALE MANY-CORE NETWORK-ON-CHIP ARCHITECTURES." Part of this<br>
>> >research will include some work with RTEMS.<br>
>> ><br>
>><br>
>> Awesome!<br>
>><br>
>> There is an asymmetric MP patch filed with a PR in bugzilla. I don't<br>
>> remember the architecture but it was a proprietary CPU with virtually<br>
>> nothing useful publicly available. The company was Kalray and here is a link<br>
>> to one of their patches.<br>
>><br>
>> <a href="http://lists.rtems.org/pipermail/bugs/2011-October/003376.html" target="_blank">http://lists.rtems.org/pipermail/bugs/2011-October/003376.html</a><br>
>><br>
>> We merged some small stuff from them but they did not work in an open<br>
>> collaborative way with the community. They have a commercial product with a<br>
>> mesh of multi core instances. I suspect the key folks have published papers.<br>
>> Assuming that is vaguely related.<br>
>><br>
>> How many is many? 16, 64,  etc.. Can you point to some example<br>
>> architectures?<br>
>><br>
> Given that I first met my supervisor today, I am currently on the stage of<br>
> collecting information, reading literature, and get sense of research work<br>
> that involves RTOS, so that we can choose which RTOS can fit on which<br>
> platform better, and of course that platform would have many cores. I asked<br>
> my supervisor this exact question, and he gave me two initial options (that<br>
> may change after readings): 1) Parallella board variants [1] that can<br>
> contain from 16 up to 64 cores (simple RISC processors) and 2) Bluestar<br>
> project that University of York research group currently works on, it has 64<br>
> cores and I may have the possibility to work on some NoC/SoC HW designs part<br>
> of my research.<br>
<br>
</div></div>I have a 16-core parallela board. I would be willing to help you in<br>
porting, at least in terms of guiding if not coding, although at this<br>
point, you're probably getting good at porting RTEMS! I believe the<br>
"Epiphany" core used by Parallela is an open-core, also.<br>
<br></blockquote><div>That will be great. Actually my supervisor first suggested parallela, </div><div>and then Bluestar. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That said, if there is enough progress on Bluestar that it won't cause<br>
you to have to wait to try using it, then you might consider leaning<br>
on the local experts there. The advantage of Parallela is that it is<br>
already shipping boards commercially, so the tool/community support is<br>
likely to be much better.<br>
<span class=""><br></span></blockquote><div>I can work on both actually. Working on Bluestar would enable me to gain</div><div>some HW experience with NoC architectures. But I will have to wait until</div><div>I get some sense of what I wanna do and which tools/platforms are best for </div><div>for that; that should be the first few months during which I will be reading </div><div>literature.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
>><br>
>><br>
>> >That said, I'd appreciate any materials (papers, publications,<br>
>> >references, tutorials, etc) that might be of help regarding that topic<br>
>> >and may or may not relate to RTEMS. I think Sebastian has contributed a<br>
>> >lot to this area recently.<br>
>><br>
>> Gedare and Sebastian are more in tune with the paper side of things.<br>
>><br>
>> My suggestion is to divide it into areas. Of the top of my head, there are<br>
>> issues with algorithm scaling as the number of cores increases, locking<br>
>> issues, more need for finer grain locks and lockless data structures, and<br>
>> likely on the application side means to debug and formally make statements<br>
>> about WCET, end to end scheduling correctness in a way that is known to be<br>
>> analyzable for schedulability and correctness, and cache effects.<br>
>><br>
> Great, I'd like to get ideas of what challenges the current RTOSes like<br>
> RTEMS face regarding many-cores systems, and I think you are the best to<br>
> tell me somethings like that.<br>
<br>
</span>As far as RTEMS goes, your best bet is to read<br>
<a href="http://www.rtems.org/wiki/index.php/SMP" target="_blank">http://www.rtems.org/wiki/index.php/SMP</a> to get a sense of the state of<br>
things. SMP is not yet working with fully-function real-time, but<br>
there aren't any open soruce hard real-time RTOS that I know of that<br>
do support SMP currently. At least, not to a satisfactory degree. (I<br>
admit, I haven't looked hard.) Sebastian may be able to give a better<br>
sense of the state of things, as he has been much closer to it for<br>
longer. I don't know what the commercial RTOS supports.<br>
<br></blockquote><div>That's a good start. I have to do a survey about the current state of SMP </div><div>support for a few RTOSes. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Some of the biggest challenges are these:<br>
1) No one has really given a good solution for migratory scheduling.<br>
Global scheduling fares poorly. Most solutions explore some kind of<br>
partitioned/clustered scheme to reduce overhead, which trades off<br>
optimality for efficiency. In this area, you should read up on Bjorn<br>
Brandenburg's work.<br>
<br>
2) Interrupt handling is a killer in SMP systems. There are more<br>
interrupts that happen now, to deal with cross-core communication, and<br>
also if there is not interrupt affinity then the hw will route the<br>
interrupt wherever it pleases, which is really bad for real-time<br>
system.<br>
<br>
A lot of the rest is just the challenge of retro-fitting a legacy<br>
code-base with the necessary synchronization and parallelism-aware<br>
primitives to allow SMP to work, and work well. The "Giant" lock that<br>
RTEMS uses is not conducive to real-time analysis, and until it goes<br>
away, the system is in no way that matters "SMP hard real-time".<br>
However, that is the direction development is going.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div>Thanks for information. I will definitely make use of it during my first review</div><div>seminar (after three months).</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
>><br>
>><br>
>> RTEMS will face the same challenges Solaris, Linux etc faced as the number<br>
>> of cores grew beyond four. So there may be useful experience papers from<br>
>> those.<br>
>><br>
>> >You may also want to suggest building some simple multi-processor<br>
>> >and/or many-core systems that RTEMS currently supports, and how to<br>
>> >simulate them.<br>
>><br>
>> Tile may be interesting but you need to look. There should be 12-16 core<br>
>> qoriq ppc by now and qemu might be up to that.<br>
>> Maestro (I think) was a MIPS based SOC out of AFRL which might be<br>
>> interesting.<br>
>><br>
>> But how many is "many" and me being at my desk will help. I just core<br>
>> dumped in an airport at 5am.<br>
>><br>
>> What do you want the code to do?<br>
>><br>
> Initially, we want the code to fit in with many-cores platforms (16-64). So,<br>
> I am trying to see how far research goes regarding this area, and the status<br>
> of some SMP libraries/APIs that current RTOSes support, and start from<br>
> there.<br>
><br>
> [1] <a href="http://www.parallella.org/board/" target="_blank">http://www.parallella.org/board/</a><br>
>><br>
>> ><br>
>> >Thanks,<br>
>> ><br>
>> >Hesham<br>
>><br>
><br>
</div></div></blockquote></div><br></div></div>