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

[Florian Weimer]

* наб:

> 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?

The kernel will always fill the buffer (if the file is large enough).
However, the application may only read the start of the file.

> 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?

Typical use of the head utility only reads a limited number of lines
at the start of the file.