linux-kernel - Re: Improve lseek scalability v3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201109161626.50000.andres@anarazel.de>
Date:	Fri, 16 Sep 2011 16:26:49 +0200
From:	Andres Freund <andres@...razel.de>
To:	Matthew Wilcox <matthew@....cx>
Cc:	Andi Kleen <andi@...stfloor.org>, viro@...iv.linux.org.uk,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Improve lseek scalability v3

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/