Messages in this thread | | | Date | Wed, 2 Oct 2002 14:14:35 +0100 | From | Matthew Wilcox <> | Subject | Re: flock(fd, LOCK_UN) taking 500ms+ ? |
| |
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.
Scheduling is a bit of a black art as far as I'm concerned. Someone with a bit more experience care to comment?
-- Revolutions do not require corporate support. - 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/
| |