Re: [patch] Voluntary Kernel Preemption, 2.6.12-rc4-mm2

[Nick Piggin <nickpiggin@yahoo.com.au>]

Ingo Molnar wrote:
> * Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
>
> > > (then you must be disagreeing with CONFIG_PREEMPT too to a certain 
> > > degree i guess?)
> >
> > CONFIG_PREEMPT is different in that it explicitly defines and delimits 
> > preempt critical sections, and allows maximum possible preemption 
> > (whether or not the critical sections themselves are too big is not 
> > really a CONFIG_PREEMPT issue).
>
>
> from a theoretical POV, this categorization into 'preempt critical' vs.  
> 'preempt-noncritical' sections is pretty arbitrary too.

Not really, is it? If so then wouldn't that be a bug.

I guess some code might hold a critical section open for longer than
it absolutely needs to, in order to gain efficiency, but basically
your're bound pretty well by critical section size.

> from a practical POV the amount of code that is non-preemptible is not 
> controllable under CONFIG_PREEMPT. So the end-result is that 
> CONFIG_PREEMPT is just as nondeterministic.

It is determined by the amount of code that is not preemptible, rather
than the maximum amount of time between sucessive calls to cond_resched.
IMO the former is cleaner.

> polling need_resched after reaching a zero preempt_count() is ugly 
> (doing cond_resched() in might_sleep() is ugly too) - pretty much the 
> only difference is overhead.
>
>
> > Jamming in cond_resched in as many places as possible seems to work 
> > quite well pragmatically, [...]
>
>
> yes, and that's what matters. It's just a single #ifdef in kernel.h, and 
> at least one major distribution would make use of it because it 
> significantly improves soft-RT latencies at a minimal cost. We can 

Yeah definitely. And in practice distos sometimes have to just go with
what works at the time. So it might be a fine solution for them indeed.

> remove it if it's not being used, but right now the only choice that 
> distributions have is no preemption or full-blown CONFIG_PREEMPT. Ask 
> the kernel maintainers at SuSE why they havent enabled CONFIG_PREEMPT in 
> their kernels.

I guess it is a number of reasons. Probably the main one had
traditionally been the chance of bugs. I guess the next big one is
return on overhead (ie. the scheduling latency soon runs into the
problem of long critical sections), although thanks to you and
others, I understand that is becoming less and less of an issue over
time too.

If a new SUSE kernel branch was started from 2.6.12 with VP turned on
rather than PREEMPT then I would probably argue against it a little
bit ;)

--
SUSE Labs, Novell Inc.

-
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/