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]

Date:	Fri, 16 Sep 2011 16:16: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.
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@...l.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
--
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/