13 Jul
2004
13 Jul
'04
10:50 p.m.
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 ;).