Re: Partitioned Scheduling
Daniel Krefft <[email protected]>
| Newsgroups | gmane.comp.micro-kernel.l4.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi, thank you for the quick reply and the exhaustive answer. Best regards Daniel On 08.09.2016 23:30, Adam Lackorzynski wrote: > Hi, > > On Mon Sep 05, 2016 at 12:49:11 +0200, Daniel Krefft wrote: >> Hi, >> >> if I understand it right, there is only one scheduler in the kernel >> realizing one distinct scheduling strategy (e.g. fixed prio). > > Yes. > >> However, >> given a multi-core system, several (all) cores are using *this* strategy >> in an independent core-local style. I'm right? > > Yes, exactly. > >> So, the questions are: >> >> - How can I enhance this approach for several scheduling schemes (not >> only one)? > > There's design space as there are currently no interfaces to select > between different scheduler variants. Currently, as there's only one > variant at a time right now, there are no abstractions in the kernel to > support multiple variants at the same time. That's probably the first > thing to add. But maybe it's easier to extend the current variant with > the feature you need and select those feature by adding parameters / > flags / etc. to the scheduling parameters. This interface is flexible in > a way that it supports different types of scheduling params. > >> - Where does the mapping between core and scheduling scheme happen? >> (e.g. compile-time/run-time) > > That's also design space but I'd say a run-time as I would assume > there's not much difference in implementation among the two. > >> - Which files do I need to change? > > All relevant files are in the src/kern directory and match sched*.cpp > and ready_queue_*.cpp, the schedule() function itself is in context.cpp > >> Maybe you can help me to get the big picture (flow chart) of scheduling >> in Fiasco.OC because it is vital for the next steps and our research. > > Scheduling is driven by the selected algorithm. For example, for the > default fixed-prio scheduler, there's an array of prios where each > element has a linked list with the ready-to-run threads. The next thread > to run is taken from the list with the highest prio that has runnable > threads. Look at ready_queue_fp.cpp and sched_context-fixed_prio.cpp. > > > > > Adam >