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

From: Ingo Molnar
Date: Wed Jun 30 2004 - 05:36:13 EST



* Povolotsky, Alexander <Alexander.Povolotsky@xxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/