This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] libio: Always use _IO_BUFSIZE for stream buffers [BZ #4099]
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Rich Felker <dalias at libc dot org>, Roland McGrath <roland at hack dot frob dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 1 Apr 2016 21:15:21 -0400
- Subject: Re: [PATCH] libio: Always use _IO_BUFSIZE for stream buffers [BZ #4099]
- Authentication-results: sourceware.org; auth=none
- References: <56E17C8E dot 1070209 at redhat dot com> <20160311215230 dot B5AF32C3C1E at topped-with-meat dot com> <56E69B9D dot 3000808 at redhat dot com> <20160318225258 dot 7D1852C3C60 at topped-with-meat dot com> <20160401181958 dot GZ21636 at brightrain dot aerifal dot cx>
On 04/01/2016 02:19 PM, Rich Felker wrote:
> On Fri, Mar 18, 2016 at 03:52:58PM -0700, Roland McGrath wrote:
>>> I can do some benchmarking, but I don't expect any compelling results.
>>
>> Whatever the results, they would not IMHO be relevant here.
>>
>> POSIX specifies that st_blksize is the "preferred I/O block size for this
>> object". It's the kernel's responsibility to give userland good advice
>> through this channel. If there are common buggy kernels that give bad
>> advice, that is a reason to apply upper and lower limits to the advice from
>> the kernel. But the expectation should be that the kernel gets fixed to
>> give good advice, and the optimal thing to do with a good kernel is to
>> follow its advice.
>>
>> Since the recommended use of st_blksize in this way is a standard user
>> feature and not just what stdio's implementation happens to do, there is an
>> argument to be made that the limiting of the value should be done in the
>> *stat functions reported st_blksize values rather than in stdio's use of
>> them. (I'm ambivalent about this point.)
>
> Regardless of st_blksize being "the preferred size", it's not suitable
> for stdio, at least not for read purposes, because sparse/random
> access reads are a valid application usage for stdio. Reading an
> unboundedly large "optimal" block size, only to use one byte and throw
> the rest away, is unacceptably pessimistic behavior and is the whole
> point behind bug 4099.
>
> If you insist on keeping unboundedly large buffers honoring
> st_blksize, one option would be to only use the full buffer for
> writing, and limit it to 4k or 8k for reading. But I think it's best
> to just ignore st_blksize and use a reasonable buffer size all the
> time.
I think Roland has a good point though, if the kernel is going to buffer
for you using filesystem-based knowledge, then why doesn't it just report
an st_blksize that's small, say 8192 bytes, given the implementation?
What purpose does it serve to set st_blksize to 2MB?
--
Cheers,
Carlos.