Re: [PATCH RFC 0/3] SUNRPC: a latency floor for interactive clients via sparse-flow dispatch

On 25 Jun 2026, at 22:45, NeilBrown wrote:
> I wonder if we should make "batch" the special case, rather than
> "interactive".
> I don't think this makes a big difference to the code (there are still
> two queues and everyone starts out interactive) but it might change how
> we think about it.
>
> I would wait a lot longer than 64 requests before considering an
> xprt to be "batch", and I would probably want to measure it in
> seconds rather than requests.  Maybe 10-15 seconds.
> I might also only consider an xprt batch if xpt_nr_rqsts remains above
> some small number - maybe 5.
>
> Maybe we could keep track of the number of "batch" xprts and compare it
> to the thread limit.  Batch xprts might only be allowed some share of
> the thread limit...
>
> If there are a bunch of READ requests on the same file, the first could
> trigger a read-ahead, and the next several might wait for that
> read-ahead, so they would all be blocked on the same thing, which can be
> pointless.  nfsd doesn;'t have any direct visibility into this, but
> limiting requests-per-xprt differently for batch and interactive might
> be useful.  non-sync WRITE requests probably behave differently...
>
> While this approach does seem pleasingly simple, I wonder how easy it
> would be for a client to accidentally start appearing to be "batch".
> Multiple interactive sessions on the one client could incorrectly
> trigger the batch detection.
>
> Maybe it would be useful to collect some statistics of what a "batch"
> stream typically looks like (OP mix, concurrency,...) as there may be a
> better signal to look for than xpt_nr_rqsts.

I like your thinking here - but while I've been putting some numbers
together for the re-arm problem Chuck was pointing out, I've found the
behavior of the server (even with this simple mechanism) to be surprisingly
complex.  The re-arm floor/ceiling is highly dependent on timing from
multiple actors.

I'm not sure I can appropriately characterize what batch looks like.  I'm
afraid I'll end up creating a heuristic monster that will hunt us down in
the future.

I'm starting to think that per-client round-robin is suddenly looking
simpler to understand and will do the right thing in most cases, but I
haven't really given up on this dual-queue setup yet.

Here's another crazy idea: instead of letting me break this for everyone,
let's leave the current behavior untouched and create a bpf interface so
folks like me can inject their desired scheduler from userspace.

Ben