This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug stdio/4099] Overly agressive caching by stream i/o functions.
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sat, 25 May 2013 12:55:48 +0000
- Subject: [Bug stdio/4099] Overly agressive caching by stream i/o functions.
- Auto-submitted: auto-generated
- References: <bug-4099-131 at http dot sourceware dot org/bugzilla/>
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.