On Thu, 9 Mar 2000, Andrea Arcangeli wrote:
> I instead propose to not make the kernel preemtable but to take the other
> way around marking some special section as preemtable.
no. First, this is definitely not going to happen before 2.5. And even in
that case we do not care about copy_user latencies. Adding 'may preempt'
areas is just as tiresome to validate as adding conditional reschedules.
We care about generic unbound kernel-space routines. Quality RT-capable
kernel code will only happen in the long run if _all_ (but a well
specified) section can be preempted and spinlocks are held for a bound
amount of time, and we do not need any explicit 'cpu_preemptable'
mechanizm for that. We _must_ identify all areas which must never be
preempted anyway (and it's not only spinlocks), so there is no need to add
a mechanizm to identify 'may preempt' areas. Such an approach also
seriously hinders the development of a preemptible kernel: all new code
added would be non-preemptible by default, so we'd be continuously hunting
and validating new code. _If_ a preemptible kernel (option) is added to
Linux then it must be an 'all inclusive' thing, otherwise it's going to be
a maintainance nightmare. The majority of Unix kernels are preemptible in
an 'inclusive' way, so it can be done and it also has another nice side
effect: it automatically makes UP code 'SMP-safe' to a fair degree.
the 'lock' example you cited in the previous mail is just a hidden
spinlock. Such code has to be changed to be 'explicit' and play nice with
any potential preemptible kernel. But please, first lets take care of 2.4
:-)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:24 EST