Re: [RFC] Remove BKL from fs/locks.c

[Christoph Hellwig <hch@infradead.org>]

On Sat, Dec 29, 2007 at 11:16:15PM -0700, Matthew Wilcox wrote:

> It seems to work well enough, but I haven't run any serious stress  
> tests on it.  This implementation uses one spinlock to protect both lock
> lists and all the i_flock chains.  It doesn't seem worth splitting up
> the locking any further.

If people are really having any kind of scalability problems with this
still it should be quite trivial to make the file_lock_list and
blocked_list aswel as the new file_lock_lock per-superblock as file
and thus locks never move between superblocks.  In fact I'd probably
do this even without scalability concerns just to make our fs data
structures nice per-superblock.

> I had to move one memory allocation out from under the file_lock_lock.
> I hope I got that logic right.  I'm rather tempted to split out the
> find_conflict algorithm from that function into something that can be
> called separately for the FL_ACCESS case.

Yes, splitting that out makes a lot of sense.  Should be a separate
patch, though.


> +static inline void lock_flocks(void)
> +{
> +	spin_lock(&file_lock_lock);
> +}
> +
> +static inline void unlock_flocks(void)
> +{
> +	spin_unlock(&file_lock_lock);
> +}

I'd rather not introduce this wrappers, they only obsfucated what's
really going on.

> +	if (found) {
> +		unlock_flocks();
>  		cond_resched();
> +		lock_flocks();
> +	}

There's a cond_resched_lock that only drops the lock in case we really
need to block.