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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ingo Molnar wrote:
* Nick Piggin <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux