Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch

[Andrea Arcangeli]

On Tue, Jul 13, 2004 at 04:32:36PM -0700, Andrew Morton wrote:
> OK.
> 
> 
> cond_resched() is usually a waste of space with CONFIG_PREEMPT.  It might
> make sense to define a cond_resched_if_not_preempt thingy, which only does
> things if !CONFIG_PREEMPT.  We'd still need to use cond_resched() inside
> lock_kernel().

Though most of the current cond_resched invocations in mainline (and the
future ones too) should be optimized away with preempt enabled, so maybe
it's simpler to just implement a cond_resched_force() that isn't
optimized away with preempt enabled and use it in lock_kernel? I'm
missing where cond_resched is needed inside lock_kernel though,
preempt_schedule already checks TIF_NEED_RESCHED by hand (on the top of
my mind I don't recall cond_rescheds that shouldn't be optimized away
with preempt enabled).

> I think Ingo's patch includes Arjan's one.  Ingo's patch apparently breaks

Ok.

> ext3.  I have a bunch of ext3 and other fixes here, but there's still an occasional
> problem on SMP.

I also had instability with it and I've seen debug checks in ext3 too
(but it's not finished anyways), and I've still a bit of printk flooding
so I'm uncertain if it's my mistake due the more strict debugging I
added in schedule() or an issue in the newer cond_resched but thanks for
the info (sounds like not all the debug checks triggering are my mistake ;).
-
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/