From: Andres Freund <andres@anarazel.de>
To: Andi Kleen <andi@firstfloor.org>
Cc: Matthew Wilcox <matthew@wil.cx>,
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:41:04 +0200 [thread overview]
Message-ID: <201109161641.04321.andres@anarazel.de> (raw)
In-Reply-To: <20110916142319.GE7761@one.firstfloor.org>
On Friday 16 Sep 2011 16:23:19 Andi Kleen wrote:
> > 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.
> I never saw that.
Hm. Not good. I see message in my imap folder marked as replied. I don't keep
mail-server logs that long though...
> Thanks for the data.
Thats Roberts work though.
> > 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.
> FWIW we did some postgres testing on a 4 socket, but only with the heavily
> patched MOSBENCH version, which fixes various locking problems. Didn't run
> it with that patchkit though.
I don't really now what MOSBENCH changed but I think some of the fixes Robert
are unlikely to be contained in there because they are more than just a rework
of locking itself but algorithmic changes on another level.
(Should it interest you its its likely to be
84e37126770dd6de903dad88ce150a49b63b5ef9,
b4fbe392f8ff6ff1a66b488eb7197eef9e1770a4,
3cba8999b343648c4c528432ab3d51400194e93b
8e5ac74c1249820ca55481223a95b9124b4a4f95, ...)
I also think youre only likely to notice those problems if youre running a
readonly test. The write-path is currently far to slow to see problems in that
area.
Greetings,
Andres
next prev parent reply other threads:[~2011-09-16 14:41 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-15 23:06 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
2011-09-16 14:23 ` Andi Kleen
2011-09-16 14:41 ` Andres Freund [this message]
2011-09-16 15:36 ` Matthew Wilcox
2011-09-16 17:27 ` Andres Freund
2011-09-16 17:39 ` [HACKERS] " Alvaro Herrera
2011-09-16 17:50 ` 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 ` [HACKERS] " Stephen Frost
2011-09-19 13:25 ` 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=201109161641.04321.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
Powered by JetHome