Re: [RFC PATCH 2/4] ksmbd: route WRITE requests to an unbound workqueue

[hehuiwen]

Hi Namjae,

在 2026/10/24 12:26, Namjae Jeon 写道:
> Since this improves performance, why isn't it enabled by default?
> Also, I would like this setting to be on/off via ksmbd.conf.

I left it off by default for now, since I've noticed some
regressions.I'm testing more cases and trying to find a general
fix. If those regressions can't be avoided, a ksmbd.conf option
would be needed.

> For 4 KiB single-channel WRITEs, throughput drops from 219.55 to
> 193.01 MiB/s. Should we add a size check here to keep small WRITEs on
> the per-CPU queue?

I tried keeping small WRITEs on PERCPU and routing only larger ones
to UNBOUND. However, this did not work well for workloads with mixed
request sizes. For example, a workload mixing 8 KiB and 64 KiB WRITEs
still regressed. Small and large WRITEs share the same connection and
send lock, so a size check alone does not avoid contention.

I then changed the send path to let one worker send several completed
WRITE responses together, without waiting for more responses. This seems
to work better:

Single-channel WRITE, 16 jobs, QD32 per job, tmpfs on a 128-CPU server,
Throughput is in MiB/s.

Size       PERCPU    UNBOUND+batch    Change
4 KiB       228.12           248.89    +6.96%
64 KiB     1797.26          2091.17   +15.34%
1 MiB      2188.42          3330.72   +53.47%

However, I found that there is still a performance regression at QD1.

1 MiB WRITE, one channel, one job:

With schedutil:

QD    PERCPU    UNBOUND+batch    Change
 1   1945.94          1021.28   -47.52%
 2   2844.66          2567.18    -9.75%
 4   2338.03          3547.42   +51.73%

Performance governor on all host CPUs:

QD    PERCPU    UNBOUND+batch    Change
 1   1974.35          1785.16    -9.58%
 2   2904.12          3038.52    +4.63%
 4   2418.45          3659.93   +51.33%


CPU frequency scaling makes the QD1 regression larger.

The main challenge seems to be balancing CPU locality and parallelism.
Keeping the work local helps QD1, while allowing it to run on another
CPU helps when receiving and processing requests in parallel. I have
not yet found a suitable policy that works well for both.

Any ideas about this?

> This walks the entire channel list and sets multichannel_seen again
> whenever an additional channel is registered. Since the flag is
> sticky, all existing channels are already marked when count > 1. Could
> we walk the list only when count == 1, marking both the existing and
> newly added connections, and update only conn->multichannel_seen when
> count > 1? This would avoid the repeated traversal and stores.

Agreed. Thanks for pointing this out.

Best regards,
Huiwen