public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug stdio/4099] Overly agressive caching by stream i/o functions. Date: Sat, 25 May 2013 12:55:00 -0000 [thread overview] Message-ID: <bug-4099-131-o9kJZXsoIf@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-4099-131@http.sourceware.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.
next prev parent reply other threads:[~2013-05-25 12:55 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-4099-131@http.sourceware.org/bugzilla/> 2012-02-21 1:35 ` jsm28 at gcc dot gnu.org 2012-12-19 10:40 ` schwab@linux-m68k.org 2013-05-20 19:49 ` ondra at iuuk dot mff.cuni.cz 2013-05-25 12:55 ` bugdal at aerifal dot cx [this message] 2013-05-25 19:20 ` neleai at seznam dot cz 2013-05-25 19:54 ` bugdal at aerifal dot cx 2013-05-26 11:53 ` neleai at seznam dot cz 2013-05-26 16:31 ` green at linuxhacker dot ru 2013-05-26 17:40 ` bugdal at aerifal dot cx 2013-05-27 1:09 ` green at linuxhacker dot ru 2014-11-28 16:15 ` carlos at redhat dot com 2020-11-02 7:56 ` [Bug stdio/4099] Overly aggressive " ldv at sourceware dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-4099-131-o9kJZXsoIf@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).