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

[Matthew Wilcox]

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.