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.


  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: link
Be 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).