[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y59uIwoECw0yHhf1@codewreck.org>
Date: Mon, 19 Dec 2022 04:46:43 +0900
From: asmadeus@...ewreck.org
To: ron minnich <rminnich@...il.com>
Cc: evanhensbergen@...oud.com, Eric Van Hensbergen <ericvh@...il.com>,
Christian Schoenebeck <linux_oss@...debyte.com>,
v9fs-developer@...ts.sourceforge.net,
Latchesar Ionkov <lucho@...kov.net>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 1/6] Adjust maximum MSIZE to account for p9 header
ron minnich wrote on Sun, Dec 18, 2022 at 08:50:18AM -0800:
> it's fine. tbh, I doubt the fact that you were fetching 31 vs 32 pages
> mattered as much as the fact that you weren't fetching *4k at a time* :-)
Yes, I think we can just blanket this as +4k and it wouldn't change
much; I've been using 1MB+4k for rdma in previous tests...
We still aren't doing things 4k at a time with this though, I'd suggest
rounding down the rsize > msize check in p9_client_read_once():
if (!rsize || rsize > clnt->msize - P9_IOHDRSZ)
rsize = clnt->msize - P9_IOHDRSZ;
to something that's better aligned; for some reason I thought we had
that already. . . but thinking again the sizes are probably driven by
the cache and will be 4k multiples already?
> > -#define DEFAULT_MSIZE (128 * 1024)
> > +/* DEFAULT MSIZE = 32 pages worth of payload + P9_HDRSZ +
> > + * room for write (16 extra) or read (11 extra) operands.
> > + */
> > +
> > +#define DEFAULT_MSIZE ((128 * 1024) + P9_HDRSZ + 16)
There's P9_IOHDRSZ for that ;)
But I guess with the comment it doesn't matter much either way.
--
Dominique
Powered by blists - more mailing lists