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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.