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

[Florian Weimer]

* наб:

> 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”.)

It's odd that increasing the buffer size beyond 8 KiB has such a large
impact in other cases.  Why is that?