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

[Nick Piggin]

Ingo Molnar wrote:
> * Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
>
>
> > I still disagree with this one violently. [...]
>
>
> (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).

Jamming in cond_resched in as many places as possible seems to
work quite well pragmatically, but is just pretty ugly for the
reasons Christoph mentioned (IMO).

The other thing is - if the users don't care about some extra
overhead, why don't they just use CONFIG_PREEMPT? Surely the case
is not that they can tolerate .5% overhead but not 1.5% (pulling
numbers out my bum).

IIRC, the reason (when you wrote the code) was that you didn't
want to enable preempt either because of binary compatibility, or
because of bugs? Well I think the bug issue is no more since your
debug patches went in, and the compatibility reason may be a fine
one for a distro kernel, but not a kernel.org one.

> > [...] If you want a cond_resched() add it where nessecary, but don't 
> > hide it behind might_sleep - there could be quite a lot might_sleeps 
> > in common codepathes and they should stay purely a debug aid.

[...]

> or if you think we can get away with using just a couple of 
> cond_resched()s then you are my guest to prove me wrong: take the -RT 
[...]

How about using CONFIG_PREEMPT instead?

--
SUSE Labs, Novell Inc.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/