Adding a new scheduling algorithm to Fiasco.OC

[Valentin Hauner]

Hi,

On 08/14/2014 11:22 PM, Adam Lackorzynski wrote:
> 3a is one of the hello threads. The thread waits for itself, with a one
> second timeout (that's the 1s), so basically it does a sleep(1).
>   
You were right. My hello application was printing "Hello World" ten
times, with a sleep after each output. I've removed this sleep call, and
things are looking better now: 'hello' prints its message ten times, as
it is supposed to. However, after it is finished, 'hello2' isn't
executed, but nothing happens (see first attachment). I've added a call
of enter_kdebug() to the main function of 'hello' just before it ends,
the second attachment contains the output of the thread list at this point.

As I have written in a previous mail, I'm starting 'hello' and 'hello2'
in 'hello.cfg'. I've changed your fp_wfq example to an fp_edf
implementation and both threads are set to my type 'Deadline' (analogous
to your type 'Wfq'). At the moment, this happens statically, i.e. the
assignment of types & deadlines is done in the constructor of the
Sched_context class (I'm aware that this is not state of the art).
All Sched_contexts with type 'Deadline' are added to my EDF ready queue,
all others to the FP ready queue.

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

Sorry for this voluminous mail and thanks again for your support!

Best regards,
Valentin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hello_hello2_execution_halts.png
Type: image/png
Size: 21305 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20140815/fb260833/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jdb-lp-hello_hello2_execution_halts.png
Type: image/png
Size: 18462 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20140815/fb260833/attachment-0001.png>