Re: [PATCH v10 7/7] NFSD: drop a shared boundary page only once both WRITEs have written it

[Mike Snitzer <snitzer@kernel.org>]

On Thu, Nov 05, 2026 at 08:33:34AM -0500, Chuck Lever wrote:
> 
> 
> On Thu, Nov 5, 2026, at 2:59 AM, Christoph Hellwig wrote:
> > On Wed, Nov 04, 2026 at 12:01:46PM -0500, Mike Snitzer wrote:
> >> It is the transfer size of IO500's ior-hard: every rank writes
> >> 47008-byte records, interleaved with the other ranks, into one shared
> >> file, with O_DIRECT.  It is meant as a hard case, and it is the
> >> workload that showed the problem on our servers.  The same happens
> >> with any record size that is not a multiple of the page size.  The
> >> cover letter also has 6000-byte records.
> >
> > So based on a bit googling your totally optimize this for an intentionally
> > stupid benchmarking workload.  And that's not been disclosed anywhere.

Why we're even debating this, like "IO500" is taboo or something, is
what's stupid.  Not a surprise: handling misaligned IO is "hard".

Public service announcement: Don't let Christoph taint others' work
with trivialities and needlessly hostile strawman arguments.

For would-be MM reviewers (and you too Jens), my previous reply to
Christoph in this thread [0] delivered a lot of useful context that
made this patchset instantly approachable and yet rather than
acknowledge that fact he attacked a misaligned IO benchmark as
irrelevant.
[0]: https://lore.kernel.org/linux-nfs/autk-osSQ8l2LKz1@kernel.org/

But anyone who is active in HPC filesystems development _knows_ that
"47008 bytes" is IOR-hard (part of IO500's benchmark suite).  And yes,
its aptly named as a "hard" workload to handle efficiently.

I have named "47008 bytes" and "IOR-hard" and "IO500" _to_ Christoph
and others multiple times before:
11 Jun 2025 https://lore.kernel.org/linux-nfs/aEl1RhqybSCAzv3H@kernel.org/
12 Jun 2025 https://lore.kernel.org/linux-nfs/aEs6gmTXzhzuDZOI@kernel.org/
29 Oct 2025 https://lore.kernel.org/linux-nfs/aQJG2LIuui08Bx3H@kernel.org/

Even in the context of this MM DONTCACHE patchset (now on v10)
Christoph's "not been disclosed anywhere" doesn't hold. IOR-hard was
named, with its 47008-byte record, on 22 October in a v7 reply he was
copied on, two weeks before v10:
https://lore.kernel.org/linux-nfs/atqCTLf42kkGZmSd@kernel.org/
But it was only in replies, never in a cover letter or commit message.

> > I guess everyone else was right and just ignored this bordline malicious
> > submission.
>
> It's not fair to ascribe that kind of intent. I think it's fairly
> well known that Mike and Jon are using IO500, and not mentioning it
> in the documentation for this series was a simple oversight.

Thanks Chuck.  If there is a need for v11 I will explicitly mention
IO500's ior-hard benchmark's use of misaligned IO of 47008 bytes.

Jeff Layton reviewed and provided his Reviewed-by.

I suspect MM engineers have just been busy with the merge window.
Hopefully Willy and/or Jens will give v10 the courtesy of fair review?

But as I mentioned in [0] any misaligned IO has this issue:
"The same happens with any record size that is not a multiple of the
page size.  The cover letter also has 6000-byte records."

> But IMO we do need a broader variety of benchmark results to
> understand the impact of these changes. IO500 on big hardware is
> an uncommon workload for NFSD.

IO500's IOR-hard reflects worst case, I understand the reluctance to
care about it BUT the reality is that not all IO is sized optimally.
So if steps can be taken to avoid pathological inefficiency during
worst case (misaligned IO) _without_ hurting the fast path (when IO is
sized properly) then why not take them?

This patchset doesn't hurt fast path at all.  But happy to take
direction for benchmarks others would like to see results for.

Mike