From: Mel Gorman <mgorman@suse.de>
To: Dave Chinner <david@fromorbit.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
Linux-FSDevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 0/5] Improve sequential read throughput v4r8
Date: Wed, 2 Jul 2014 00:09:49 +0100 [thread overview]
Message-ID: <20140701230949.GZ10819@suse.de> (raw)
In-Reply-To: <20140701223817.GI4453@dastard>
On Wed, Jul 02, 2014 at 08:38:17AM +1000, Dave Chinner wrote:
> On Tue, Jul 01, 2014 at 07:39:15PM +0100, Mel Gorman wrote:
> > On Tue, Jul 01, 2014 at 01:16:11PM -0400, Johannes Weiner wrote:
> > > On Mon, Jun 30, 2014 at 05:47:59PM +0100, Mel Gorman wrote:
> > > Seqread throughput is up, randread takes a small hit. But allocation
> > > latency is badly screwed at higher concurrency levels:
> >
> > So the results are roughly similar. You don't state which filesystem it is
> > but FWIW if it's the ext3 filesystem using the ext4 driver then throughput
> > at higher levels is also affected by filesystem fragmentation. The problem
> > was outside the scope of the series.
>
> I'd suggest you're both going wrong that the "using ext3" point.
>
> Use ext4 or XFS for your performance measurements because that's
> what everyone is using for the systems these days. iNot to mention
> they don'thave all the crappy allocation artifacts that ext3 has,
> nor the throughput limitations caused by the ext3 journal, and so
> on.
>
> Fundamentally, ext3 performance is simply not a relevant performance
> metric anymore - it's a legacy filesystem in maintenance mode and
> has been for a few years now...
>
The problem crosses filesystems. ext3 is simply the first in the queue
because by and large it behaved the worst. Covering the rest of them
simply takes more time and with different results as you may expect. Here
are the xfs results for the smaller of the machines as it was able to get
that far before it got reset
3.16.0-rc2 3.0.0 3.16.0-rc2
vanilla vanilla fairzone-v4
Min SeqRead-MB/sec-1 92.69 ( 0.00%) 99.68 ( 7.54%) 104.47 ( 12.71%)
Min SeqRead-MB/sec-2 106.81 ( 0.00%) 123.43 ( 15.56%) 123.24 ( 15.38%)
Min SeqRead-MB/sec-4 101.89 ( 0.00%) 113.78 ( 11.67%) 116.85 ( 14.68%)
Min SeqRead-MB/sec-8 95.31 ( 0.00%) 91.40 ( -4.10%) 101.68 ( 6.68%)
Min SeqRead-MB/sec-16 81.84 ( 0.00%) 88.53 ( 8.17%) 86.63 ( 5.85%)
--
Mel Gorman
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2014-07-01 23:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-30 16:47 [PATCH 0/5] Improve sequential read throughput v4r8 Mel Gorman
2014-06-30 16:48 ` [PATCH 1/4] mm: pagemap: Avoid unnecessary overhead when tracepoints are deactivated Mel Gorman
2014-06-30 16:48 ` [PATCH 2/4] mm: Rearrange zone fields into read-only, page alloc, statistics and page reclaim lines Mel Gorman
2014-06-30 16:48 ` [PATCH 3/4] mm: vmscan: Do not reclaim from lower zones if they are balanced Mel Gorman
2014-06-30 16:48 ` [PATCH 4/4] mm: page_alloc: Reduce cost of the fair zone allocation policy Mel Gorman
2014-06-30 21:14 ` Andrew Morton
2014-06-30 21:51 ` Mel Gorman
2014-06-30 22:09 ` Andrew Morton
2014-07-01 8:02 ` Mel Gorman
2014-07-01 17:16 ` [PATCH 0/5] Improve sequential read throughput v4r8 Johannes Weiner
2014-07-01 18:39 ` Mel Gorman
2014-07-01 20:58 ` Mel Gorman
2014-07-01 21:25 ` Johannes Weiner
2014-07-02 15:44 ` Johannes Weiner
2014-07-02 15:53 ` Mel Gorman
2014-07-01 22:38 ` Dave Chinner
2014-07-01 23:09 ` Mel Gorman [this message]
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=20140701230949.GZ10819@suse.de \
--to=mgorman@suse.de \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=hannes@cmpxchg.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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).