From: Andres Freund <andres@anarazel.de>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Andi Kleen <andi@firstfloor.org>,
viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: Improve lseek scalability v3
Date: Fri, 16 Sep 2011 16:16:49 +0200 [thread overview]
Message-ID: <201109161616.50004.andres@anarazel.de> (raw)
In-Reply-To: <20110916130054.GA8997@parisc-linux.org>
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.
I sent an email containing benchmarks from Robert Haas regarding the Subject.
Looking at lkml.org I can't see it right now, Will recheck when I am at home.
He replaced lseek(SEEK_END) with fstat() and got speedups up to 8.7 times the
lseek performance.
The workload was 64 clients hammering postgres with a simple readonly workload
(pgbench -S).
For reference see the thread in the postgres archives which also links to
performance data: http://archives.postgresql.org/message-
id/CA+TgmoawRfpan35wzvgHkSJ0+i-W=VkJpKnRxK2kTDR+HsanWA@mail.gmail.com
You likely won't be able to see the bottlenecks with any of the released
postgres versions as there are bottlenecks fixed in HEAD that throttle way
before that.
In the other mail I wrote that I forward ported v1 of this patch to v3.1-rc1
and tested it on the biggest machine I could easily reboot into an
experimental kernel.
That machine was only a 2 socket x 4 cores (+ht) nehalem machine though. The
benefits I measured at it were between 1-3% if memory serves right. Its not
surprising though that the problem is not that visible at such a comparatively
low concurrency.
In Roberts Tests the concurrency difference started to show at around 40
clients.
I looked at all the patches (as I said V1 some weeks back) and they looked
reasonable to me.
My aforementioned machine runs v1 rebased onto newer kernels for the last
weeks without problems.
Greetings,
Andres
next prev parent reply other threads:[~2011-09-16 14:23 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-15 23:06 Improve lseek scalability v3 Andi Kleen
2011-09-15 23:06 ` [PATCH 1/7] BTRFS: Fix lseek return value for error Andi Kleen
2011-09-15 23:47 ` Thomas Gleixner
2011-09-16 15:48 ` Christoph Hellwig
2011-09-16 16:38 ` Andi Kleen
2011-09-17 6:10 ` Jeff Liu
2011-09-17 23:03 ` Andreas Dilger
2011-09-18 1:46 ` Andi Kleen
2011-09-18 7:29 ` Jeff Liu
2011-09-18 8:42 ` Marco Stornelli
2011-09-18 10:33 ` Jeff liu
2011-09-18 14:55 ` Chris Mason
2011-09-19 17:52 ` Andi Kleen
2011-09-19 19:30 ` Chris Mason
2011-09-19 19:59 ` Andi Kleen
2011-09-19 22:55 ` Chris Mason
2011-09-15 23:06 ` [PATCH 2/7] VFS: Do (nearly) lockless generic_file_llseek Andi Kleen
2011-09-15 23:06 ` [PATCH 3/7] VFS: Make generic lseek lockless safe Andi Kleen
2011-09-15 23:06 ` [PATCH 4/7] VFS: Add generic_file_llseek_size Andi Kleen
2011-09-16 15:50 ` Christoph Hellwig
2011-09-15 23:06 ` [PATCH 5/7] LSEEK: EXT4: Replace cut'n'pasted llseek code with generic_file_llseek_size Andi Kleen
2011-09-15 23:06 ` [PATCH 6/7] LSEEK: NFS: Drop unnecessary locking in llseek Andi Kleen
2011-09-15 23:06 ` [PATCH 7/7] LSEEK: BTRFS: Avoid i_mutex for SEEK_{CUR,SET,END} Andi Kleen
2011-09-16 13:00 ` Improve lseek scalability v3 Matthew Wilcox
2011-09-16 13:19 ` Josef Bacik
2011-09-16 14:16 ` Andres Freund [this message]
2011-09-16 14:23 ` Andi Kleen
2011-09-16 14:41 ` Andres Freund
2011-09-16 15:36 ` Matthew Wilcox
2011-09-16 17:27 ` Andres Freund
2011-09-16 17:39 ` Alvaro Herrera
2011-09-16 17:50 ` [HACKERS] " Andi Kleen
2011-09-16 20:08 ` Benjamin LaHaise
2011-09-16 21:02 ` Andres Freund
2011-09-16 21:05 ` [HACKERS] " Andres Freund
2011-09-16 22:44 ` Greg Stark
2011-09-19 12:31 ` Stephen Frost
2011-09-19 13:25 ` [HACKERS] " Matthew Wilcox
2011-09-20 7:18 ` Marco Stornelli
2011-09-19 13:30 ` Robert Haas
2011-09-16 14:26 ` Andres Freund
2011-10-01 20:46 ` Andres Freund
2011-10-01 20:49 ` [PATCH 1/2] LSEEK: BTRFS: Avoid i_mutex for SEEK_{CUR,SET,END} Andres Freund
2011-11-02 8:29 ` Christoph Hellwig
2011-11-05 15:27 ` Chris Mason
2012-03-07 17:16 ` Andres Freund
2011-10-01 20:50 ` [PATCH 2/2] btrfs: Don't have multiple paths to error out in btrfs_file_llseek Andres Freund
2011-10-02 5:28 ` Improve lseek scalability v3 Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201109161616.50004.andres@anarazel.de \
--to=andres@anarazel.de \
--cc=andi@firstfloor.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).