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.