This is the mail archive of the glibc-bugs@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]

[Bug stdio/4099] Overly agressive caching by stream i/o functions.


http://sourceware.org/bugzilla/show_bug.cgi?id=4099

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
mmap is not the solution; mmap-by-default is not an option because it will
SIGBUS under circumstances you cannot control. The solution is just decoupling
cache size from st_blksize, either never using st_blksize at all (and avoiding
the expensive fstat syscall at open time if possible) or only using it when
it's less than a reasonable upper bound like 8-64k.

As far as I can tell, the better solution is NEVER to use st_blksize for stdio.
The only time it might make sense is for files opened in O_SYNC mode,
unbuffered block devices, etc. But for normal files the way stdio uses them,
the kernel already does its own caching, the efficiency of which has little or
nothing to do with the size of read/write units. The purpose of stdio buffering
is not to match the underlying storage device's transfer units, just to
overcome the syscall overhead of read/write. For this purpose, a fixed buffer
size somewhere between 1k and 8k seems to be plenty large, from an empirical
standpoint.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


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