You miss nothing I think. In fact it's already used (see below)
>
> > > 2. Isn't it possible to get in trouble even on a UP if a task
> > > is preempted in a critical region? For example, suppose the
> > > preempting task does a synchronize_kernel()?
> >
> > Ugly. I guess one way to solve it would be to readd the 2.2 scheduler
> > taskqueue, and just queue a scheduler callback in this case.
>
> Another approach would be to define a "really low" priority that noone
> other than synchronize_kernel() was allowed to use. Then the UP
> implementation of synchronize_kernel() could drop its priority to
> this level, yield the CPU, and know that all preempted tasks must
> have obtained and voluntarily yielded the CPU before synchronize_kernel()
> gets it back again.
That just would allow nasty starvation, e.g. when someone runs a cpu intensive
screensaver or a seti-at-home.
>
> I still prefer suppressing preemption on the read side, though I
> suppose one could claim that this is only because I am -really-
> used to it. ;-)
For a lot of reader cases non-preemption by threads is guaranteed anyways --
e.g. anything that runs in interrupts, timers, tasklets and network softirq.
I think that already covers a lot of interesting cases.
-Andi
-
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/