mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox