From: "Wang Zhaolong" <wangzhaolong@fygo.io>
To: "Namjae Jeon" <linkinjeon@kernel.org>
Cc: <linux-cifs@vger.kernel.org>,
"Wang Zhaolong" <wangzhaolong@fygo.io>, <smfrench@gmail.com>,
<senozhatsky@chromium.org>, <tom@talpey.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: [RFC 3/3] ksmbd: use splice payloads for simple SMB2 READ
Date: Fri, 17 Jul 2026 20:49:40 +0800 [thread overview]
Message-ID: <alok5KscSC-xurtR@MiniServer> (raw)
In-Reply-To: <CAKYAXd-ymPFFLwW+a6_88LHL_tZXEuffUW8NymbSp3t+OZHosw@mail.gmail.com>
On Mon, Jul 13, 2026 at 05:58:46PM +0900, Namjae Jeon wrote:
> On Mon, Jul 13, 2026 at 4:18 PM wang zhaolong <wangzhaolong@fnnas.com> wrote:
> >
> > From: Wang Zhaolong <wangzhaolong@fnnas.com>
> Hi Wang,
>
> Could you rebase the series on the current #ksmbd-for-next-next branch
> to test this ?
> >
> > Use the page-backed payload path for plain TCP SMB2 READ requests of at
> > least 64 KiB.
> Could you provide benchmark results ? and requests smaller than 64 KiB
> are unlikely to benefit from this optimization? Theoretically, it
> seems like it would improve, but I am wondering how much performance
> improvement there actually is.
>
Hi Namjae,
Thank you for the review.
I rebased the series on the current ksmbd-for-next-next branch. Functional
smoke testing passed.
---
Environment: one QEMU guest; ksmbd and the SMB client communicate over
loopback CIFS; warm 4 GiB regular file; SMB 3.1.1; cache=none; one
synchronous fio read job; 5 s ramp; 60 s runtime.
request sizes: 4, 16, 32, 64, 128, 256 KiB, 1 MiB
thresholds: baseline, 4, 16, 32, 64, 128, 256 KiB
formal matrix: 12 matched blocks, 252 valid selected cells
control cells: 65 single-sample threshold/path-validation cells
total: 317 accepted observations; no valid selected cell discarded
The formal results below use whole-block paired bootstrap 95% confidence
intervals and Holm correction. BW, mean clat, and P99 clat are ratios to the
baseline; a BW ratio above 1 is better, and latency ratios below 1 are better.
## RFC 64 KiB threshold versus baseline
request BW ratio [95% CI] Holm p mean clat P99 clat
64 KiB 1.262 [1.217, 1.304] +26.2% 0.00537 0.790 -21.0% 0.780 -22.0%
128 KiB 1.317 [1.274, 1.357] +31.7% 0.00537 0.757 -24.3% 0.730 -27.0%
256 KiB 1.450 [1.424, 1.478] +45.0% 0.00537 0.688 -31.2% 0.591 -40.9%
1 MiB 1.403 [1.315, 1.496] +40.3% 0.00537 0.712 -28.8% 0.778 -22.2%
## Experimental 4 KiB threshold versus baseline
This forces the same splice path for the sub-64 KiB requests.
request BW ratio [95% CI] Holm p mean clat P99 clat result
4 KiB 1.052 [1.031, 1.074] +5.2% 0.01270 0.950 -5.0% 0.948 -5.2% ambiguous
16 KiB 1.135 [1.095, 1.174] +13.5% 0.01270 0.878 -12.2% 0.883 -11.7% beneficial
32 KiB 1.172 [1.151, 1.193] +17.2% 0.00537 0.851 -14.9% 0.842 -15.8% beneficial
64 KiB 1.277 [1.245, 1.306] +27.7% 0.00537 0.781 -21.9% 0.774 -22.6% beneficial
128 KiB 1.335 [1.289, 1.378] +33.5% 0.00537 0.746 -25.4% 0.724 -27.6% beneficial
256 KiB 1.440 [1.398, 1.485] +44.0% 0.00537 0.693 -30.7% 0.602 -39.8% beneficial
1 MiB 1.415 [1.343, 1.487] +41.5% 0.00537 0.706 -29.4% 0.765 -23.5% beneficial
## Same-splice control: RFC 64 KiB threshold versus 4 KiB threshold
request BW ratio [95% CI] result
64 KiB 0.989 [0.965, 1.012] equivalent
128 KiB 0.987 [0.969, 1.004] equivalent
256 KiB 1.007 [0.984, 1.028] equivalent
1 MiB 0.991 [0.941, 1.042] ambiguous
## Threshold-boundary controls
Each entry is `path / BW change versus the same-run baseline`. L is the legacy
path and S is the splice path. These are single-sample controls, not inputs to
the formal statistical result.
threshold 4 KiB 16 KiB 32 KiB 64 KiB 128 KiB 256 KiB
4 KiB S/+4.95% S/+13.78% S/+21.14% S/+26.40% S/+35.47% -
16 KiB L/+2.65% S/+11.84% S/+20.20% S/+26.42% S/+38.27% -
32 KiB L/-1.86% L/-0.53% S/+20.28% S/+27.48% S/+44.22% -
64 KiB L/+4.67% L/+2.54% L/+3.52% S/+32.22% S/+44.22% -
128 KiB L/+2.71% L/+6.43% L/+0.73% L/+3.89% S/+41.74% -
256 KiB L/+3.65% L/+13.00% L/+4.18% L/+8.38% L/-6.54% S/+31.55%
The ftrace path oracle matched every threshold boundary: below the threshold,
ksmbd_vfs_read handled the request; at and above the threshold,
ksmbd_vfs_read_payload and ksmbd_tcp_write_read_payload handled it.
The 4 KiB result is not sufficient for a threshold decision: its confidence
interval lower bound is +3.1%, below the predeclared +5% benefit criterion.
The data support splice-path benefit from 16 KiB upward in this environment.
I will keep 64 KiB as the conservative initial threshold for this RFC. It has
strong results and avoids the inconclusive 4 KiB case. The 16 KiB threshold is
a reasonable follow-up candidate.
Best regards,
Wang Zhaolong
prev parent reply other threads:[~2026-07-17 12:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 7:11 [RFC 0/3] ksmbd: use splice for SMB2 READ responses wang zhaolong
2026-07-13 7:11 ` [RFC 1/3] ksmbd: add read payload infrastructure wang zhaolong
2026-07-13 7:11 ` [RFC 2/3] ksmbd: add splice-based read payload helper wang zhaolong
2026-07-13 7:11 ` [RFC 3/3] ksmbd: use splice payloads for simple SMB2 READ wang zhaolong
2026-07-13 8:58 ` Namjae Jeon
2026-07-13 9:36 ` Wang Zhaolong
2026-07-17 12:49 ` Wang Zhaolong [this message]
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=alok5KscSC-xurtR@MiniServer \
--to=wangzhaolong@fygo.io \
--cc=linkinjeon@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=senozhatsky@chromium.org \
--cc=smfrench@gmail.com \
--cc=tom@talpey.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.