Adding a new scheduling algorithm to Fiasco.OC

Adam Lackorzynski adam at os.inf.tu-dresden.de
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
requests.

> 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
overview.





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




More information about the l4-hackers mailing list