Partitioned Scheduling

[Daniel Krefft]

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
>