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

On Mon, Jun 29, 2026, at 8:41 AM, Benjamin Coddington wrote:
> So I read this as the argument for the low-watermark refill you floated:
> re-arm when depth drops below a small threshold rather than at exactly 0.
> A watermark of even 2-4 would move the W=1 column's behavior out to cover
> the modestly-pipelined flows, while still excluding a real bulk client
> (which sits far above any sane watermark).  It doesn't reintroduce identity
> and it's a one-line change to the refill condition.
>
> I could spin that as a 4th patch for v1 and re-run this sweep against it --
> I'd expect the protected band to widen from "W<=1" to "W<=watermark".  Does
> a fixed small watermark match your intuition, or were you thinking of
> deriving it (thread count, or the slot-table hint you mentioned)?

Hey Ben,

Thanks for running this, and thanks to the clanker too. Two things fell out
when I put the numbers next to the refill code, and together they push me
past the watermark model and toward letting the credit decay more gracefully.

The first is that the budget resets to a full SVC_XPRT_HI_BURST every time
the transport idles; it doesn't accumulate. So a flow doesn't need a high
depth==0 fraction to stay protected, but rather it only needs to hit zero
once per 64 high-priority dispatches. That reframes the W=2 collapse:

0.4% is below 1/64 (~1.6%), so the flow runs dry between idle moments and
falls to the bulk queue. Your uncontended histogram sat at 25.6%, which is
16x above that line. So the question we care about isn't whether the
depth==0 fraction "holds up", it's whether a real interactive workload
under load stays north of ~1.6%.
  
That's the metric we still don't have. The synthetic victim refills
instantly and idles as rarely as it can, so it answers a question we
already knew the answer to: a flow that never goes idle never re-arms on
idle. Before changing anything I'd want the same depth==0 probe under
load against a real workload: a cold tree walk, git status, a build's
header reads, instead of the fixed-window generator. If those stay above
1.6%, exact-zero is fine and we'd be polishing a non-problem.

The second thing is about the watermark itself. Because the credit resets
to full whenever the trigger fires, the trigger is binary per flow: a flow
either re-arms often enough to live on the high queue forever, or it
spends its 64 once and settles in the bulk queue. Exact-zero puts that
split between W=1 and W=2. A watermark of N doesn't soften the split, it
slides it to between W=N and W=N+1. Anything under the watermark gets near-
permanent residency, anything over it demotes wholesale, same as today. So
fixed vs derived is really just picking where to stand the cliff, not
/whether/ there's a cliff.

If what we actually want is for protection to fade as a flow gets busier
rather than snap off at a line, the budget has to decay instead of reset.
Roughly: spend a credit per high-priority dispatch as it does now, but on
the idle transition add back a fraction of the budget instead of slamming
it to 64. A flow with frequent gaps tops up faster than it spends and
keeps its place. A flow that idles rarely bleeds down and slides into the
bulk queue gradually, in proportion to how backlogged it really is.

I haven't pinned the refill fraction, and that wants the same sweep your
harness already does. If you're up for it, I'd love three lines on your
axes: exact-zero (the RFC), a fixed watermark, and a decaying credit. My
bet is the first two are cliffs in different spots and the third is a
ramp. If the ramp lands where we want the protected band to sit, it
answers the fixed-vs-derived question by making it moot.

Let's get the real-workload depth==0 numbers first, because if they stay
high under load, none of the rest matters.


-- 
Chuck Lever