Adding a new scheduling algorithm to Fiasco.OC

Adam Lackorzynski adam at
Wed Aug 13 22:23:33 CEST 2014

On Tue Aug 12, 2014 at 10:05:46 +0200, Valentin Hauner wrote:
> On 08/11/2014 11:35 PM, Adam Lackorzynski wrote:
> > I'd assume that the ready queue also has moe because moe should be
> > ready. Wouldn't, with a requeue, sigma0 moved behind moe now (next
> > deadline of sigma0 is further away)? On the other side, sigma0 is not
> > done with that single message, so it also should be continuing
> > execution. Who's running when the output stops?
> >   
> Are sigma0 and moe periodic tasks that are active as long as the whole
> system is up? Or are they just active during the init phase?

Neither. They have an init phase and during run-time they handle client

> In theory, the ready queue of a EDF scheduler isn't rotated, but
> contains all Sched_contexts sorted by their deadlines.
> Meanwhile, I have added a separate ready queue for my deadline based
> threads. So currently, there are two ready queues: One that contains all
> ordinary threads (sigma0, moe etc.) and one that contains my deadline
> based threads only.
> The ordinary ready queue is rotated with that method mentioned in my
> previous mail whenever a requeue request arrives. The deadline ready
> queue is not rotated.
> Adapted from your fp_wfq example, the thread to run next is determined
> as follows:
> >[...]
> >Ready_queue_edf<E>::next_to_run() const
> >{
> >  if (!deadlineRq.empty())
> >    return deadlineRq.front();
> >
> >  return rq.front();
> >}
> I.e. whenever there is a thread in my deadline ready queue, it is chosen
> for execution. However, the execution ends up with the following error:

Ok, good approach.
> >[...]
> >MOE: Hello world
> >[...]
> >MOE: loading 'rom/ned'
> >[...]
> >Ned: loading file: 'rom/hello.cfg'
> >Inserted id:5 in ordinary rq!
> >Inserted id:3 in ordinary rq!
> >Inserted id:4 in ordinary rq!
> >Inserted id:3 in ordinary rq!
> >Inserted id:4 in ordinary rq!
> >Inserted id:8 in ordinary rq!
> >Inserted id:4 in ordinary rq!
> >Inserted id:3 in ordinary rq!
> >
> >Inserted id:9 with deadline=10 in deadlineRq (content of deadlineRq:
> 9->end)
> >
> >Inserted id:8 in ordinary rq!
> >
> >Got requeue call for id:9 - reinserted!
> >./kernel/fiasco/src/kern/thread-ipc.cpp:456: ASSERTION FAILED
> (!(state() & Thread_ipc_mask))
> I'm assigning identification numbers to the threads in the order of
> their creation time. So my two threads launched in hello.cfg are those
> with id 9 and 11 (the latter does not appear in the example above).
> Consequently, Fiasco creates 8 kernel threads (?) before mine.
> Why does that assertion fail?

The assertion says that when starting an IPC, none of the IPC-related
thread state flags must be enabled. Print state() before the assertion
to know which one and get some more info.

> Obviously, some of the kernel threads have
> to be executed before, but which? The ordinary ready queue will never
> become empty as it is a cyclic queue with rotation.

When I boot pure hello, I get 4 + num_cpus threads (sigma0, moe, hello
and hello's l4re_kernel, plus one idler per CPU). With ned it's two
more. How many CPU's do you have? And look at 'lp' in the jdb to get an

Adam                 adam at

More information about the l4-hackers mailing list