Messages in this thread |  | | | Date | Tue, 29 Jan 2002 17:26:41 -0800 | | From | Andrew Morton <> | | Subject | Re: [PATCH] 2.5: push BKL out of llseek |
| |
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.
- - 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/
|  |