lkml.org 
[lkml]   [2004]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Preemption of the OS system call due to expiration of the time-sl ice for: a) SCHED_NORMAL (aka SCHED_OTHER) b) SCHED_RR

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

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.044 / U:1.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site