Hi Oak,
The timeslice value on the master kernel is only reset on thread creation and once the thread is depleted, so when a thread drops its priority the timeslice will not change, so it'll run for 2ms.
The timeslice cannot be set to lower than 1 ms, however you could change the timer driver on your target platform to do so (look at the initTimer function).
Note that the scheduler on the master kernel is fairly basic, the RT branch is far more fully featured (tickless and you can set different timeslices per thread).
Cheers
Anna.
Thank you, Anna and Gernot for the answer.
One more question, so assuming a timeslice is 5ms, a thread with the highest priority has run for 3ms, then drops its priority to be the same as the other thread.Then, the same thread will start running with the fresh timeslice and it will run for another 5ms or will it just run for 2ms to complete the timeslice?
Oak
On Mon, Oct 16, 2017 at 3:09 PM, <Anna.Lyons@data61.csiro.au> wrote:
Hi Oak,
Assuming your questions are about the master branch of the kernel, as on the RT branch the kernel is tickless.
1. There are two config paramters
+ TIMER_TICK_MS is how many milliseconds per tick
+ TIME_SLICE is how many ticks per timeslice.
2. Assuming a thread is waiting on a notification object for an irq to arrive, and another thread is running at the same priority when the irq arrives, the thread waiting on the notification object will not be woken until the currently running thread has exhausted it's timeslice.
Cheers,
Anna.
From: Devel <devel-bounces@sel4.systems> on behalf of Norrathep Rattanavipanon <nrattana@uci.edu>
Sent: Tuesday, 17 October 2017 8:35 AM
To: devel@sel4.systems
Subject: [seL4] Questions on seL4's schedulingHello,
I have a few questions about seL4's scheduling model in the main (formally verified) branch.
1) I see the time slice parameter in make menuconfig. Is that where I can change the scheduler's time slice correct? And the unit is in timer tick period I suppose?
2) I kind of remember the discussion we had that if an interrupt handler has lower priority than the currently running task, then the interrupt wouldnt happen.So what if both of them have the same priority, would the kernel schedule the currently running task until it uses up all of its timeslice, then issues the interrupt notification or would the interrupting process get executed right away?
Best Regards,Oak
--
Norrathep (Oak) RattanavipanonM.S. in Computer ScienceUniversity of California - Irvine
--
Norrathep (Oak) RattanavipanonM.S. in Computer ScienceUniversity of California - Irvine