Messages in this thread | | | From | Andres Freund <> | Subject | Re: Improve lseek scalability v3 | Date | Fri, 16 Sep 2011 16:26:49 +0200 |
| |
On Friday 16 Sep 2011 15:00:55 Matthew Wilcox wrote: > On Thu, Sep 15, 2011 at 04:06:46PM -0700, Andi Kleen wrote: > > Currently generic_file_llseek users synchronize all on the inode i_mutex, > > which is very heavy handed because it affects even different processes. > > > > This patchkit attempts to make generic_file_llseek (mostly) lockless. > > Yes, but, are there any real workloads which care? I know will-it-scale > says that lseek doesn't scale, but any real app which has a seek-heavy > workload is surely using pread()/pwrite() by now ... after all, they > were in UNIX98 so they've been a standard for 13 years. Postgres uses llseek() to check wether the filesize has changed, pread()/pwrite() won't help with that. An unlocked llseek will likely be faster than fstat(). Especially if the latter invokes some LSM module which lseek doesn't do.
Now postgres certainly could start synchronizing the filesize in shared memory between processes, but ...
Andres
| |