Answer related to threads running under the >= 2.6.23 linux CFS SCHED_RR scheduling policy.
the kernel provides time slices for different processes / tasks.
This is not precisely true. A better understanding is possible if we reword your statement as follows : For each thread, the scheduler computes some time quantum.
It seems that the kernel will initialize a timer, and when the timer
times out, this will cause the current task to be interrupted and the
kernel then gets control.
This is wrong. As written earlier, the scheduler only computed some time value. No timer went directly associated, no timer interrupt will get fired when the time quantum is reached.
No worry! The scheduler will run about any time whatever IRQ is fired, which, at the very worst case concerning latency should happen at least at CPU_HZ frequency. And about any time the scheduler runs it considers the run queues and recomputes its red-black trees.
If, at the time the scheduler runs, one SCHED_RR task is running and all other SCHED_RR tasks are blocked (waiting for whatever event) and no other real-time scheduled task of higher priority can run then… that very task won't get scheduled out, possibly running for longer than its associated time quantum.
If another SCHED_RR task can run then, if the running task had got the cpu for an amount of time greater or equal to its time quantum then it will be scheduled out and thrown at the back of the queue (given the lowest priority) while the task that could run is scheduled in.
Your last question is IMHO not related to the principal point of this question and should better be made part of another thread.
