public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "sgk at troutmask dot apl dot washington dot edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/21820] Really, really, horrible IO performance
Date: Mon, 30 May 2005 16:21:00 -0000 [thread overview]
Message-ID: <20050530162050.10245.qmail@sourceware.org> (raw)
In-Reply-To: <20050530143227.21820.kargl@gcc.gnu.org>
------- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-05-30 16:20 -------
Subject: Re: Really, really, horrible IO performance
On Mon, May 30, 2005 at 03:20:18PM -0000, pinskia at gcc dot gnu dot org wrote:
>
> I see the same thing on powerpc-darwin but it seems like on freebsd,
> it is actually paging in the memory which seems wrong, I almost want
> to say you should report it to freebsd as their performance bug
> (Yes working around in libgfortran is still a good idea).
It appears to be a faulty assumption in how gfortran uses mmap.
gfortran appears to assume Linux's behavior:
(From some version of Redhat)
MAP_SHARED Share this mapping with all other processes that map this
object. Storing to the region is equivalent to writing to
the file. The file may not actually be updated until
msync(2) or munmap(2) are called.
(From FreeBSD)
MAP_SHARED Modifications are shared.
MAP_NOSYNC Causes data dirtied via this VM map to be flushed to
physical media only when necessary (usually by the
pager) rather than gratuitously. Typically this pre-
vents the update daemons from flushing pages dirtied
through such maps and thus allows efficient sharing of
memory across unassociated processes using a file-
backed shared memory map. (Much snipped, including a
big warning about ftruncate extending a file).
(From http://www.opengroup.org/onlinepubs/7990989775/xsh/mmap.html)
If MAP_SHARED is specified, write references change the underlying object.
It appears that Linux's MAP_SHARED is equivalent to FreeBSD's
(MAP_SHARED | MAP_NOSYNC). NetBSD and OpenBSD man pages do not
have the MAP_NOSYNC flag, so they may not be affected. Note
POSIX doesn't state anything about when and how the underlying object
is updated. POSIX also doesn't include a MAP_NOSYNC flag.
I've verified that the following patch works and improves
performance, but I prefer the original O_TRUNC patch because
O_TRUNC is a POSIX flag and AFAIK most OS's implement it.
Index: unix.c
===================================================================
RCS file: /cvs/gcc/gcc/libgfortran/io/unix.c,v
retrieving revision 1.26
diff -c -p -r1.26 unix.c
*** unix.c 17 May 2005 16:54:51 -0000 1.26
--- unix.c 30 May 2005 16:06:54 -0000
*************** mmap_alloc (unix_stream * s, gfc_offset
*** 622,628 ****
length = ((where - offset) & page_mask) + 2 * page_size;
! p = mmap (NULL, length, s->prot, MAP_SHARED, s->fd, offset);
if (p == (char *) MAP_FAILED)
return FAILURE;
--- 622,628 ----
length = ((where - offset) & page_mask) + 2 * page_size;
! p = mmap (NULL, length, s->prot, MAP_SHARED | MAP_NOSYNC, s->fd, offset);
if (p == (char *) MAP_FAILED)
return FAILURE;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21820
next prev parent reply other threads:[~2005-05-30 16:21 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-30 14:33 [Bug libfortran/21820] New: " kargl at gcc dot gnu dot org
2005-05-30 14:33 ` [Bug libfortran/21820] " kargl at gcc dot gnu dot org
2005-05-30 14:49 ` pinskia at gcc dot gnu dot org
2005-05-30 15:00 ` sgk at troutmask dot apl dot washington dot edu
2005-05-30 15:01 ` pinskia at gcc dot gnu dot org
2005-05-30 15:17 ` sgk at troutmask dot apl dot washington dot edu
2005-05-30 15:34 ` pinskia at gcc dot gnu dot org
2005-05-30 16:21 ` sgk at troutmask dot apl dot washington dot edu [this message]
2005-05-31 7:51 ` fxcoudert at gcc dot gnu dot org
2005-05-31 10:57 ` fxcoudert at gcc dot gnu dot org
2005-05-31 17:01 ` sgk at troutmask dot apl dot washington dot edu
2005-08-16 19:12 ` tobi at gcc dot gnu dot org
2005-09-04 9:49 ` jblomqvi at cc dot hut dot fi
2005-09-11 11:10 ` jblomqvi at cc dot hut dot fi
[not found] <bug-21820-10110@http.gcc.gnu.org/bugzilla/>
2005-11-01 21:22 ` tobi at gcc dot gnu dot org
2005-11-01 22:09 ` jblomqvi at cc dot hut dot fi
2005-11-01 22:31 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
2005-12-09 9:24 ` fxcoudert at gcc dot gnu dot org
2005-12-09 15:09 ` sgk at troutmask dot apl dot washington dot edu
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=20050530162050.10245.qmail@sourceware.org \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.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).