On Tue, Oct 28, 2014 at 6:06 AM, Gedare Bloom <ged...@gwmail.gwu.edu> wrote:
> On Mon, Oct 27, 2014 at 4:43 PM, Hesham Moustafa > <heshamelmat...@gmail.com> wrote: > > > > > > On Mon, Oct 27, 2014 at 2:30 PM, Joel Sherrill < > joel.sherr...@oarcorp.com> > > wrote: > >> > >> > >> > >> On October 27, 2014 3:04:26 AM PDT, Hesham Moustafa > >> <heshamelmat...@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. > > I have a 16-core parallela board. I would be willing to help you in > porting, at least in terms of guiding if not coding, although at this > point, you're probably getting good at porting RTEMS! I believe the > "Epiphany" core used by Parallela is an open-core, also. > > That will be great. Actually my supervisor first suggested parallela, and then Bluestar. > That said, if there is enough progress on Bluestar that it won't cause > you to have to wait to try using it, then you might consider leaning > on the local experts there. The advantage of Parallela is that it is > already shipping boards commercially, so the tool/community support is > likely to be much better. > > I can work on both actually. Working on Bluestar would enable me to gain some HW experience with NoC architectures. But I will have to wait until I get some sense of what I wanna do and which tools/platforms are best for for that; that should be the first few months during which I will be reading literature. > >> > >> > >> >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. > > As far as RTEMS goes, your best bet is to read > http://www.rtems.org/wiki/index.php/SMP to get a sense of the state of > things. SMP is not yet working with fully-function real-time, but > there aren't any open soruce hard real-time RTOS that I know of that > do support SMP currently. At least, not to a satisfactory degree. (I > admit, I haven't looked hard.) Sebastian may be able to give a better > sense of the state of things, as he has been much closer to it for > longer. I don't know what the commercial RTOS supports. > > That's a good start. I have to do a survey about the current state of SMP support for a few RTOSes. > Some of the biggest challenges are these: > 1) No one has really given a good solution for migratory scheduling. > Global scheduling fares poorly. Most solutions explore some kind of > partitioned/clustered scheme to reduce overhead, which trades off > optimality for efficiency. In this area, you should read up on Bjorn > Brandenburg's work. > > 2) Interrupt handling is a killer in SMP systems. There are more > interrupts that happen now, to deal with cross-core communication, and > also if there is not interrupt affinity then the hw will route the > interrupt wherever it pleases, which is really bad for real-time > system. > > A lot of the rest is just the challenge of retro-fitting a legacy > code-base with the necessary synchronization and parallelism-aware > primitives to allow SMP to work, and work well. The "Giant" lock that > RTEMS uses is not conducive to real-time analysis, and until it goes > away, the system is in no way that matters "SMP hard real-time". > However, that is the direction development is going. > > Thanks for information. I will definitely make use of it during my first review seminar (after three months). > >> > >> > >> 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 > >> > > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
