Adding a new scheduling algorithm to Fiasco.OC

Adam Lackorzynski adam at os.inf.tu-dresden.de
Mon Aug 18 23:39:40 CEST 2014


On Fri Aug 15, 2014 at 11:29:11 +0200, Valentin Hauner wrote:
> > Sched_context::Sched_context(unsigned short no)
> > {
> >  if (no == 9 || no == 11) {
> >    printf("Created Sched_context object with type:Deadline (no.
> %d)\n", no);
> >    _t = Deadline;
> >    if (no == 9)
> >      _sc.edf._dl = 10;
> >    if (no == 11)
> >      _sc.edf._dl = 20;
> >  } else {
> >    _t = Fixed_prio;
> >    [...]
> >  }
> > }
> 
> 'no' is just a counter, i.e. no. 9 means that it's the 9th Sched_context
> object created (it's just an auxiliary construction as I cannot access
> the dbg_id in the constructor). The dbg_id of thread with no. 9
> respectively 11 are 3a respectively 41.
> 
> Is it neccessary to 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.
> If I change their types to 'Deadline', the following happens:
> > [...]
> > Enqueuing Sched_context object in edf_rq (cid:34)
> > Trying to insert cid:34... - inserted, same deadline: 9
> > Enqueuing Sched_context object in edf_rq (cid:34)
> > Trying to insert cid:34... - inserted, same deadline: 9
> > Thread_ipc_mask: 28 ; state flags: 0000000000001001
> > ./kernel/fiasco/src/kern/thread-ipc.cpp:464: ASSERTION FAILED
> (!(state() & Thread_ipc_mask))
> 
> Interesting is the thread list entry for #hello:
> >    id    cpu    name             pr     sp   wait  to  state
> >    [...]
> >    34        0   #hello              0     33        a      
> ready,rcv_wait
> 
> #hello seems to wait for moe, which does not come to execution because
> FP threads ain't be executed as long as my EDF ready queue contains
> elements.

For me this setup looks like 34 queries something from moe (likely a
memory mapping) because 35(?) page faulted. Which thread is still ready
in this situation? With both hellos sleeping for 1s there should rarely
be someone ready. Putting the two also in the EDF queue can not be the
solution I think because IPC dependencies exist (may exist) throughout
the system so that every thread (down the dependency graph) would end up
there.





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