Re: [PATCH] 2.5: push BKL out of llseek

[Andrew Morton <akpm@zip.com.au>]

Robert Love wrote:
> 
> @@ -84,9 +84,9 @@
>         fn = default_llseek;
>         if (file->f_op && file->f_op->llseek)
>                 fn = file->f_op->llseek;
> -       lock_kernel();
> +       down(&file->f_dentry->d_inode->i_sem);
>         retval = fn(file, offset, origin);
> -       unlock_kernel();
> +       up(&file->f_dentry->d_inode->i_sem);
>         return retval;
>  }

Just a little word of caution here.  Remember the
apache-flock-synchronisation fiasco, where removal
of the BKL halved Apache throughput on 8-way x86.

This was because the BKL removal turned serialisation
on a quick codepath from a spinlock into a schedule().

So...  I'd suggest that changes such as this should be
benchmarked in isolation; otherwise we end up spending
quite some time hunting down mysterious reports of
performance regression, and having to rethink stuff.

And llseek is *fast*.  If we're seeing significant
lock contention in there then adding a schedule() is
likely to turn Anton into one unhappy dbencher.

-