Re: flock(fd, LOCK_UN) taking 500ms+ ?

From: Matthew Wilcox (willy@debian.org)
Date: Wed Oct 02 2002 - 08:14:35 EST


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/



This archive was generated by hypermail 2b29 : Mon Oct 07 2002 - 22:00:34 EST