Messages in this thread | | | Date | Mon, 13 Mar 2000 14:14:49 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: new IRQ scalability changes in 2.3.48 |
| |
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/
| |