On 24 Jul 2024, at 08:52, Peter Chubb via Devel wrote:

...

...

...

...

...

"liam" == liam vervecken writes:

liam> Hello, I'm trying to understand MCS and how the scheduling works liam> but I'm running into some issues. My setup: RISCV on liam> BeagleVFire in sel4test

liam> I have configured 2 threads: liam> seL4_SchedControl_ConfigureFlags(info->schedcontrol.start, liam> sched_context_thread2, 1000000, 1000000, 0, 0, 0); liam> seL4_SchedContext_Bind(sched_context_thread2, thread2_TCB);

liam> seL4_SchedControl_ConfigureFlags(info->schedcontrol.start, liam> sched_context_thread3, 1000000, 1000000, 0, 0, 0); liam> seL4_SchedContext_Bind(sched_context_thread3, thread3_TCB);

The only times that the seL4 kernel will preempt a running thread are: -- if a higher priority thread becomes runnable, or -- if the running thread runs out of budget.

Your example sets budget==period so no thread will ever run out of budget and all threads will run until they wait on an event or call sched_yield().

To get the effect you want, set period to twice the budget, so each thread takes up half the available time.

Nope, that’s not how it’s supposed to work, and if that’s what the implementation does then that’s a bug. A thread should always be preempted if its budget is depleted. A depleted budget is replenished once the new period begins. If budget=period, then that’s immediate. After budget replenishment, the thread should be inserted back at the end of the ready queue. This means, a full budget acts like a normal time slice, with threads of equal priority scheduled round-robin. Gernot

On Tue, Jul 23, 2024, 8:15 PM Gerwin Klein via Devel wrote:

If the first thread is round-robin, that means it is always the highest priority thread as soon as it gets started, and the second thread never gets started at all, because the sel4test setup thread does not run any more (since the first thread is always ready).

Keeping the setup thread priority high until after both round-robin threads are started (and then dropping it) shows the correct round robin behaviour for me.

I noticed a similar issue, but I have all the threads at the same priority and the scheduler seems to be behaving more like a FIFO scheduler than a round-robin one. I haven't actually looked at the scheduler code all that much yet so I'm not quite sure what's going on. I am using a fork rather than seL4 itself, but this was happening before I started making major changes.