Subject: Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch
From: Andrea Arcangeli (andrea_AT_suse.de)
Date: Wed Jul 14 2004 - 03:40:01 EEST
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 ;).
This archive was generated by hypermail 2b28 : Wed Jul 14 2004 - 21:05:17 EEST