Adding a new scheduling algorithm to Fiasco.OC

[Adam Lackorzynski]

On Sun Aug 17, 2014 at 20:51:40 +0200, Valentin Hauner wrote:
> I've solved the problem explained in my mail from August 15th. There was
> a bug in my implementation of 'Ready_queue_edf::dequeue' so that a
> thread which already finished didn't get removed properly from the queue.

Ok, good.

> By the way, what's the exact meaning of the attribute named
> '_ready_link' in your fp_wfq implementation? As far as I got it, it's
> set to 0 if the Sched_context is idle and it's set to the address of the
> enqueued Sched_context if it is not idle.

Looks like _ready_link is used for implementing the ready list.

> However, the second question in my mail from August 15th is still
> relevant:  Shall I enqueue the threads with dbg_id 34 (#hello) and 3e
> (#hello2) in the EDF ready queue, too? At the moment, they are ordinary
> FP threads.

I replied to that now.

> On 08/11/2014 11:35 PM, Adam Lackorzynski wrote:
> > You add
> >  l:start({ ..., 
> >            scheduler = L4.Env.user_factory:create(L4.Proto.Scheduler, ...),
> >          }, ...)
> > statements.
> > For the fixed-prio type, we add two numbers, giving upper limit and base
> >  (e.g. L4.Env.user_factory:create(L4.Proto.Scheduler, 10, 5). However,
> > for using this in the lua scripting, you also need to adapt libkproxy.
> > So for the start, I'd suggest you use the C/C++ interface and reconfig
> > the main thread from the defaults just in your program.
> >
> > In your case, the numbers used have a different meaning of course.
> > Passing them down to the kernel goes via Scheduler::run_thread. There's
> > some support for different scheduling parameters in the kernel, you've
> > probably seen 'union Sp'. You can probably squeeze it in there.
> >   
> OK, my goal is to define the type (Fixed_prio or Deadline) for each
> thread directly in my LUA script. Depending on the type, it should be
> possible to pass the priority respectively the deadline for the thread.
> 
> I guess that './l4/pkg/libkproxy/include/scheduler_svr' contains the
> code snippet that extracts the information supplied in the LUA script
> (lines 92-102, 'case L4_SCHEDULER_RUN_THREAD_OP'). Is that right?

Yes, this code snippet is used to take the parameters out of the IPC of
a Scheduler::run_thread call.
 
> Unfortunately, I cannot find the base priority you mentioned.

That is done by calling create() with Proto=Scheduler on an appropriate
Factory that in turn creates a Scheduler object with the created config.
Now this describes it a bit too abstract maybe. The kernel factory does
not support creating additional scheduler objects, that is, this is a
user-level object only. The allocator/factory in moe is in
moe/server/src/alloc.cc where you'll also find the creation of a
Scheduler (Proxy) Object. The base and max values are extracted there
and stored in the Sched_proxy object. For any run_thread call that goes
through this Sched_proxy, the base and max values will be used to adjust
the given prio.

> Furthermore, the struct 'L4_sched_param_fixed_prio' does not have
> attributes for 'affinity.offset' and 'affinity.granularity' that are set
> in scheduler_svr.

Indeed. They are handled separately in the kernel's scheduler.cpp
sys_run method.

> I've tried your example with an upper limit of 10 and a base priority of
> 5 for my two tasks created in my LUA script, but the 'pr' column in the
> thread list of JDB still shows 1 for #hello and #hello2.

When implementing a new scheduler you might also need to adapt the
functionality in jdb to properly show all values. I'm not sure this
might be the problem here. Otherwise the prios show ok?



Adam
-- 
Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/