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 ;).