From: "J. Bruce Fields" <bfields@fieldses.org>
To: Shyam Kaushik <shyamnfs1@gmail.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: Need help with NFS Server SUNRPC performance issue
Date: Tue, 5 Nov 2013 14:58:10 -0500 [thread overview]
Message-ID: <20131105195810.GC23329@fieldses.org> (raw)
In-Reply-To: <CA+uAZNOJg3Jeu8uyCEeHx71JwHwC0P0d=mx1BiyKnyoS04KUsw@mail.gmail.com>
On Tue, Nov 05, 2013 at 07:14:50PM +0530, Shyam Kaushik wrote:
> Hi Bruce,
>
> You are spot on this issue. I did a quicker option of just fixing
>
> fs/nfsd/nfs4proc.c
>
> nfsd_procedures4[]
>
> NFSPROC4_COMPOUND
> instead of
> .pc_xdrressize = NFSD_BUFSIZE/4
>
> I made it by /8 & I got double the IOPs. I moved it /16 & now I see
> that 30 NFSD threads out of 32 that I have configured are doing the
> nfsd_write() job. So yes this is the exact problematic area.
Yes, that looks like good evidence we're on the right track, thanks very
much for the testing.
> Now for a permanent fixture for this issue, what do you suggest? Is it
> that before processing the compound we adjust svc_reserve()?
I think decode_compound() needs to do some estimate of the maximum total
reply size and call svc_reserve() with that new estimate.
And for the current code I think it really could be as simple as
checking whether the compound includes a READ op.
That's because that's all the current xdr encoding handles. We need to
fix that: people need to be able to fetch ACLs larger than 4k, and
READDIR would be faster if it could return more than 4k of data at a go.
After we do that, we'll need to know more than just the list of ops,
we'll need to e.g. know which attributes exactly a GETATTR requested.
And we don't have any automatic way to figure that out so it'll all be a
lot of manual arithmetic. On the other hand the good news is we only
need a rough upper bound, so this will may be doable.
Beyond that it would also be good to think about whether using
worst-case reply sizes to decide when to accept requests is really
right.
Anyway here's the slightly improved hack--totally untested except to fix
some compile errors.
--b.
diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
index d9454fe..947f268 100644
--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -1617,6 +1617,7 @@ nfsd4_decode_compound(struct nfsd4_compoundargs *argp)
struct nfsd4_op *op;
struct nfsd4_minorversion_ops *ops;
bool cachethis = false;
+ bool foundread = false;
int i;
READ_BUF(4);
@@ -1667,10 +1668,15 @@ nfsd4_decode_compound(struct nfsd4_compoundargs *argp)
* op in the compound wants to be cached:
*/
cachethis |= nfsd4_cache_this_op(op);
+
+ foundread |= op->opnum == OP_READ;
}
/* Sessions make the DRC unnecessary: */
if (argp->minorversion)
cachethis = false;
+ if (!foundread)
+ /* XXX: use tighter estimates, and svc_reserve_auth: */
+ svc_reserve(argp->rqstp, PAGE_SIZE);
argp->rqstp->rq_cachetype = cachethis ? RC_REPLBUFF : RC_NOCACHE;
DECODE_TAIL;
next prev parent reply other threads:[~2013-11-05 19:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-31 6:49 Need help with NFS Server SUNRPC performance issue Shyam Kaushik
2013-10-31 14:15 ` J. Bruce Fields
2013-10-31 14:45 ` Michael Richardson
2013-10-31 15:14 ` J. Bruce Fields
2013-11-01 19:09 ` Michael Richardson
2013-11-04 23:03 ` J. Bruce Fields
2013-11-01 4:43 ` Shyam Kaushik
2013-11-13 4:07 ` Shyam Kaushik
2013-11-13 16:18 ` Bruce Fields
2013-11-01 4:38 ` Shyam Kaushik
2013-11-04 23:02 ` J. Bruce Fields
2013-11-05 13:44 ` Shyam Kaushik
2013-11-05 19:58 ` J. Bruce Fields [this message]
2013-11-06 7:27 ` Shyam Kaushik
2013-11-13 16:24 ` J. Bruce Fields
2013-11-13 22:00 ` J. Bruce Fields
2013-11-14 4:23 ` Shyam Kaushik
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=20131105195810.GC23329@fieldses.org \
--to=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=shyamnfs1@gmail.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.