From: Dave Chinner <david@fromorbit.com>
To: Anna Schumaker <Anna.Schumaker@netapp.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
Trond Myklebust <trond.myklebust@primarydata.com>,
Marc Eshel <eshel@us.ibm.com>,
xfs@oss.sgi.com, Christoph Hellwig <hch@infradead.org>,
linux-nfs-owner@vger.kernel.org
Subject: Re: [PATCH v3 3/3] NFSD: Add support for encoding multiple segments
Date: Thu, 16 Apr 2015 08:57:45 +1000 [thread overview]
Message-ID: <20150415225745.GW13731@dastard> (raw)
In-Reply-To: <552EBCB2.1040609@Netapp.com>
On Wed, Apr 15, 2015 at 03:32:02PM -0400, Anna Schumaker wrote:
> I just ran some more tests comparing the directio case across
> different filesystem types. These tests used three 1G files:
> 100% data, 100% hole, and mixed file with alternating 4k data and
> hole segments. The mixed case seems to be consistently slower
> compared to NFS v4.1, and I'm at a loss for anything I could do to
> make it faster. Here are my numbers:
>
> ###########
> # #
> # XFS #
> # #
> ###########
>
>
> NFS v4.1:
> Trial
> |---------|---------|---------|---------|---------|---------|---------|
> | | 1 | 2 | 3 | 4 | 5 | Average |
> |---------|---------|---------|---------|---------|---------|---------|
> | Data | 1.883s | 1.808s | 1.781s | 1.685s | 1.591s | 1.746s |
> | Hole | 1.815s | 1.635s | 1.682s | 1.698s | 1.653s | 1.697s |
> | Mixed | 2.089s | 2.024s | 1.970s | 1.925s | 2.049s | 2.011s |
> |---------|---------|---------|---------|---------|---------|---------|
>
>
> NFS v4.2:
> Trial
> |---------|---------|---------|---------|---------|---------|---------|
> | | 1 | 2 | 3 | 4 | 5 | Average |
> |---------|---------|---------|---------|---------|---------|---------|
> | Data | 1.849s | 1.879s | 1.852s | 1.799s | 1.781s | 1.832s |
> | Hole | 0.668s | 0.600s | 0.611s | 0.619s | 0.617s | 0.623s |
> | Mixed | 5.913s | 5.811s | 5.952s | 5.962s | 5.806s | 5.889s |
> |---------|---------|---------|---------|---------|---------|---------|
What that says to me is that the READ_PLUS when there are (worst
case) mixed holes is either burning a lot more CPU than we expected
or it is serialising somewhere (not sure where, everything in XFS
should be shared locks on read/seek).
Can you run a perf profile (even just a snapshot from perf top) on
the server so we can see a bit about what is happening on the CPU
for the different workloads?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Anna Schumaker <Anna.Schumaker@netapp.com>
Cc: Christoph Hellwig <hch@infradead.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
Trond Myklebust <trond.myklebust@primarydata.com>,
Marc Eshel <eshel@us.ibm.com>,
xfs@oss.sgi.com, "J. Bruce Fields" <bfields@fieldses.org>,
linux-nfs-owner@vger.kernel.org
Subject: Re: [PATCH v3 3/3] NFSD: Add support for encoding multiple segments
Date: Thu, 16 Apr 2015 08:57:45 +1000 [thread overview]
Message-ID: <20150415225745.GW13731@dastard> (raw)
In-Reply-To: <552EBCB2.1040609@Netapp.com>
On Wed, Apr 15, 2015 at 03:32:02PM -0400, Anna Schumaker wrote:
> I just ran some more tests comparing the directio case across
> different filesystem types. These tests used three 1G files:
> 100% data, 100% hole, and mixed file with alternating 4k data and
> hole segments. The mixed case seems to be consistently slower
> compared to NFS v4.1, and I'm at a loss for anything I could do to
> make it faster. Here are my numbers:
>
> ###########
> # #
> # XFS #
> # #
> ###########
>
>
> NFS v4.1:
> Trial
> |---------|---------|---------|---------|---------|---------|---------|
> | | 1 | 2 | 3 | 4 | 5 | Average |
> |---------|---------|---------|---------|---------|---------|---------|
> | Data | 1.883s | 1.808s | 1.781s | 1.685s | 1.591s | 1.746s |
> | Hole | 1.815s | 1.635s | 1.682s | 1.698s | 1.653s | 1.697s |
> | Mixed | 2.089s | 2.024s | 1.970s | 1.925s | 2.049s | 2.011s |
> |---------|---------|---------|---------|---------|---------|---------|
>
>
> NFS v4.2:
> Trial
> |---------|---------|---------|---------|---------|---------|---------|
> | | 1 | 2 | 3 | 4 | 5 | Average |
> |---------|---------|---------|---------|---------|---------|---------|
> | Data | 1.849s | 1.879s | 1.852s | 1.799s | 1.781s | 1.832s |
> | Hole | 0.668s | 0.600s | 0.611s | 0.619s | 0.617s | 0.623s |
> | Mixed | 5.913s | 5.811s | 5.952s | 5.962s | 5.806s | 5.889s |
> |---------|---------|---------|---------|---------|---------|---------|
What that says to me is that the READ_PLUS when there are (worst
case) mixed holes is either burning a lot more CPU than we expected
or it is serialising somewhere (not sure where, everything in XFS
should be shared locks on read/seek).
Can you run a perf profile (even just a snapshot from perf top) on
the server so we can see a bit about what is happening on the CPU
for the different workloads?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-04-15 22:57 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-16 21:18 [PATCH v3 0/3] NFSD: Add READ_PLUS support Anna Schumaker
2015-03-16 21:18 ` [PATCH v3 1/3] NFSD: nfsd4_encode_read{v}() should encode eof and maxcount Anna Schumaker
2015-03-16 21:18 ` [PATCH v3 2/3] NFSD: Add basic READ_PLUS support Anna Schumaker
2015-03-16 21:18 ` [PATCH v3 3/3] NFSD: Add support for encoding multiple segments Anna Schumaker
2015-03-17 19:56 ` J. Bruce Fields
2015-03-17 20:07 ` J. Bruce Fields
2015-03-17 21:36 ` J. Bruce Fields
2015-03-18 18:16 ` Anna Schumaker
2015-03-18 18:55 ` J. Bruce Fields
2015-03-18 20:39 ` Anna Schumaker
2015-03-18 20:55 ` J. Bruce Fields
2015-03-18 21:03 ` Anna Schumaker
2015-03-18 21:11 ` J. Bruce Fields
[not found] ` <OFB111A6D8.016B8BD5-ON88257E0D.001D174D-88257E0D.005268D6@us.ibm.com>
2015-03-19 15:36 ` J. Bruce Fields
2015-03-19 16:28 ` Marc Eshel
2015-03-20 15:17 ` J. Bruce Fields
2015-03-20 15:17 ` J. Bruce Fields
2015-03-20 16:23 ` Christoph Hellwig
2015-03-20 16:23 ` Christoph Hellwig
2015-03-20 18:26 ` J. Bruce Fields
2015-03-20 18:26 ` J. Bruce Fields
2015-03-24 12:43 ` Anna Schumaker
2015-03-24 12:43 ` Anna Schumaker
2015-03-24 17:49 ` Christoph Hellwig
2015-03-24 17:49 ` Christoph Hellwig
2015-03-25 17:15 ` Anna Schumaker
2015-03-25 17:15 ` Anna Schumaker
2015-03-26 15:21 ` Anna Schumaker
2015-03-26 15:21 ` Anna Schumaker
2015-03-26 15:32 ` Trond Myklebust
2015-03-26 15:32 ` Trond Myklebust
2015-03-26 15:36 ` Anna Schumaker
2015-03-26 15:36 ` Anna Schumaker
2015-03-26 15:38 ` J. Bruce Fields
2015-03-26 15:38 ` J. Bruce Fields
2015-03-26 15:47 ` Anna Schumaker
2015-03-26 15:47 ` Anna Schumaker
2015-03-26 16:06 ` Trond Myklebust
2015-03-26 16:06 ` Trond Myklebust
2015-03-26 16:11 ` Anna Schumaker
2015-03-26 16:11 ` Anna Schumaker
2015-03-26 16:13 ` Trond Myklebust
2015-03-26 16:13 ` Trond Myklebust
2015-03-26 16:14 ` Anna Schumaker
2015-03-26 16:14 ` Anna Schumaker
2015-03-27 19:04 ` Anna Schumaker
2015-03-27 19:04 ` Anna Schumaker
2015-03-27 20:22 ` Trond Myklebust
2015-03-27 20:22 ` Trond Myklebust
2015-03-27 20:46 ` Anna Schumaker
2015-03-27 20:46 ` Anna Schumaker
2015-03-27 20:54 ` J. Bruce Fields
2015-03-27 20:54 ` J. Bruce Fields
2015-03-27 20:55 ` Anna Schumaker
2015-03-27 20:55 ` Anna Schumaker
2015-03-27 21:08 ` J. Bruce Fields
2015-03-27 21:08 ` J. Bruce Fields
2015-04-15 19:32 ` Anna Schumaker
2015-04-15 19:32 ` Anna Schumaker
2015-04-15 19:56 ` J. Bruce Fields
2015-04-15 19:56 ` J. Bruce Fields
2015-04-15 20:00 ` J. Bruce Fields
2015-04-15 20:00 ` J. Bruce Fields
2015-04-15 22:50 ` Dave Chinner
2015-04-15 22:50 ` Dave Chinner
2015-04-17 22:07 ` J. Bruce Fields
2015-04-17 22:07 ` J. Bruce Fields
2015-04-15 22:57 ` Dave Chinner [this message]
2015-04-15 22:57 ` Dave Chinner
2015-03-26 16:11 ` J. Bruce Fields
2015-03-26 16:11 ` J. Bruce Fields
2015-03-26 16:18 ` Anna Schumaker
2015-03-26 16:18 ` Anna Schumaker
2015-03-30 14:06 ` Christoph Hellwig
2015-03-30 14:06 ` Christoph Hellwig
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=20150415225745.GW13731@dastard \
--to=david@fromorbit.com \
--cc=Anna.Schumaker@netapp.com \
--cc=bfields@fieldses.org \
--cc=eshel@us.ibm.com \
--cc=hch@infradead.org \
--cc=linux-nfs-owner@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@primarydata.com \
--cc=xfs@oss.sgi.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.