On Fri, Jun 24, 2016 at 09:31:07PM +0000, Trond Myklebust wrote:
>
> > On Jun 24, 2016, at 17:18, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote:
> >
> > On Fri, Jun 24, 2016 at 10:55:51AM -0400, Trond Myklebust wrote:
> >> Instead of trying (and failing) to predict how much writeable socket space
> >> will be available to the RPC call, just fall back to the simple model of
> >> deferring processing until the socket is uncongested.
> >
> > OK, it would be a relief to get rid of that, I guess that explains the
> > previous patch.
> >
> > But was there some specific reason you were running into this?
>
> I’ve been testing using a 40GigE network, which easily hits this bottleneck. The result is that each connection saturates long before we’re even near the saturation of the network or even the disk. So we find ourselves with a server that can continue to scale up to several 100 clients, but with each client seeing the same low performance irrespective of the total number of clients.
OK, I'm stealing some of your responses for a slightly more verbose
changelog (see below), but otherwise committing the patches unchanged
for 4.8. Thanks!
--b.
SUNRPC: Change TCP socket space reservation
The current server rpc tcp code attempts to predict how much writeable
socket space will be available to a given RPC call before accepting it
for processing. On a 40GigE network, we've found this throttles
individual clients long before the network or disk is saturated. The
server may handle more clients easily, but the bandwidth of individual
clients is still artificially limited.
Instead of trying (and failing) to predict how much writeable socket space
will be available to the RPC call, just fall back to the simple model of
deferring processing until the socket is uncongested.
This may increase the risk of fast clients starving slower clients; in
such cases, the previous patch allows setting a hard per-connection
limit.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
