Re: Preemption of the OS system call due to expiration of the time-sl ice for: a) SCHED_NORMAL (aka SCHED_OTHER) b) SCHED_RR

[Ingo Molnar <mingo@elte.hu>]

* Povolotsky, Alexander <Alexander.Povolotsky@marconi.com> wrote:

> Con - thanks for your kind answers !
> 
> Preemption (due to the expiration of the time-slice) of the process,
> while it executes OS system call, - by another process (of equal or
> higher priority) when running under following scheduling policies:
> 
>  a) SCHED_NORMAL (aka SCHED_OTHER)
>  b) SCHED_RR 
> 
> Is it possible in Linux 2.6 ? Linux 2.4 ?

this is possible in 2.6 in CONFIG_PREEMPT is on. There's no guaranteed
latency due to non-preemptability of interrupts and critical sections
but the practical latencies are well below 1 msec. A bad driver or some
rare codepath we missed could introduce long latencies - but these are
usually easy to fix.

The core 2.6 kernel itself is very latency-friendly, in a very
controlled hardware environment utilizing well-reviewed userspace code,
a slimmed down kernel, no block IO and no high-rate interrupt source
(other than the interrupt source the application cares about) i'd say
it's quite close to hard-RT: all kernel functions have bound latency,
'all' you have to take care of are latencies introduced by hardware
interrupts.

in 2.4 kernel-preemption is done too in lots of places conditionally
(cooperatively), by kernel code. Unlike 2.6 there's no forced preemption
of kernel code.

	Ingo