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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
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