All of lore.kernel.org
 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 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.