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