Matthew Wilcox wrote:
>
> On Wed, Oct 02, 2002 at 04:23:27AM +0100, John Levon wrote:
> > --- linux-linus/fs/locks.c Sat Sep 28 15:56:28 2002
> > +++ linux/fs/locks.c Wed Oct 2 04:15:54 2002
> > @@ -727,11 +727,11 @@
> > }
> > unlock_kernel();
> >
> > - if (found)
> > - yield();
> > -
> > if (new_fl->fl_type == F_UNLCK)
> > return 0;
> > +
> > + if (found)
> > + yield();
> >
> > lock_kernel();
> > for_each_lock(inode, before) {
> >
> > "fixes" the problem (a simultaneous kernel compile is going on; it's a
> > 2-way SMP machine). What is the yield for ? What's the right fix (if
> > any) ? This turns our app's main loop from a second or two into a
> > 90-second behemoth.
>
> I'm pretty sure this is correct. There's no particular reason to yield()
> if we're unlocking.
>
> I wonder if yield() is the correct call to make anyway. We certainly need
> to schedule() to allow any higher-priority task the opportunity to run.
> But if we're the highest-priority task downgrading our write-lock to
> a read-lock which permits other tasks the opportunity to run, i see no
> reason we should _yield_ to them.
>
sched_yield() sementics changed a lot. It used to mean "take a quick
nap", but it now means "go to the back of the runqueue and stay there
for absolutely ages". The latter is a closer interpretation of the spec,
but it has broken stuff which was tuned to the old behaviour.
It's not really clear why that yield is in there at all? Unless that
code is really, really slow (milliseconds) then probably it should just
be deleted.
If there really is a solid need to hand the CPU over to some now-runnable
higher-priority process then a cond_resched() will suffice.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 07 2002 - 22:00:35 EST