[PATCH] io: allow filesystem st_blksize-directed buffer sizes up to 128k instead of 8k

[наб]

On Mon, Dec 29, 2025 at 12:30:04PM +0100, Florian Weimer wrote:
> * наб:
> > The only difference between old and new being
> >   setvbuf(input, (char *)malloc(128*1024), _IOFBF, 128*1024);
> > with 128k matching zfs's st_blksize:
> >   Benchmark 1: < f  out/cmd/head -n 290955
> >     Time (mean ± σ):     153.4 ms ±   3.9 ms    [User: 78.0 ms, System: 75.3 ms]
> >     Range (min … max):   146.5 ms … 159.2 ms    19 runs
> >
> >   Benchmark 2:  < f ./head.old -n 290955
> >     Time (mean ± σ):     259.7 ms ±   5.7 ms    [User: 86.3 ms, System: 173.3 ms]
> >     Range (min … max):   249.1 ms … 269.3 ms    11 runs
> >
> >   Summary
> >     < f  out/cmd/head -n 290955 ran
> >       1.69 ± 0.06 times faster than  < f ./head.old -n 290955
> > (where the output is 290955 lines, 230427757 bytes and the program
> >  reduces to a getdelim()/fwrite() loop which reduces to a read()/write()
> >  loop).
> >
> > A value around 128k gets us around 60% of the performance back
> > without being so large it should affect the memory pressure.
> 
> It's probably not memory pressure, but that we tell the kernel to fill
> the entire large buffer even if the allocation will only use a part of
> it.  (Based on that the test program is called “head”.)

I don't get what you mean by this. I think it's very reasonable to
expect the kernel to be able to fill a block with the size it
tells us to use to be optimal optimally?
And that we'll therefore use the whole thing before underflowing.
This is the behaviour I reproduce.

The test program is called head because it's voreutils head(1);
it's pretty much immaterial here beyond being getdelim()/fwrite()
and it inspects the whole buffer (since it does getdelim()),
as noted under the hyperfine results?

> It's odd that increasing the buffer size beyond 8 KiB has such a large
> impact in other cases.  Why is that?
What other cases are there? What is this referencing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251229/f64afb4b/attachment.sig>