This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] libio: Always use _IO_BUFSIZE for stream buffers [BZ #4099]


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.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]