From: James Bottomley <James.Bottomley@steeleye.com>
To: "David S. Miller" <davem@redhat.com>
Cc: hugh@veritas.com, willy@debian.org,
Linux Kernel <linux-kernel@vger.kernel.org>,
PARISC list <parisc-linux@lists.parisc-linux.org>,
drepper@redhat.com
Subject: Re: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc)
Date: 24 Aug 2003 11:54:00 -0500 [thread overview]
Message-ID: <1061744042.13315.29.camel@mulgrave> (raw)
In-Reply-To: <20030823222300.4695a0c4.davem@redhat.com>
On Sun, 2003-08-24 at 00:23, David S. Miller wrote:
> This is what I'm asking of you, to find cases in real life,
> not some contrived example, where your optimization helps
> appreciably.
Oh, OK, that's easy...it's what the glibc test was designed for.
In glibc, for each file you fopen as a mapped file, you seem to get a
separate mmapping of the file (this actually looks wrong to me...it
seems glibc should have only one mapping per file which all the file
objects share, but anyway). That means we get one entry in one of the
i_mmaps lists for each of the opens. Since these are files, the chances
are they'll be read and written which will generate lots of dcache
flushes. This case would kill us if we had to flush every entry in
i_mmap.
Right at the moment, you have to specifically request that the file be
mmapped by specifying the "m" modifier, but glibc seems to be migrating
to this being the default one day...that's what I want to be ready for.
Besides the optimisation adds no overhead and compromises nothing, so
its worth doing regardless.
James
next prev parent reply other threads:[~2003-08-24 16:54 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-22 14:40 Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) James Bottomley
2003-08-22 16:14 ` David S. Miller
2003-08-22 16:34 ` [parisc-linux] " Matthew Wilcox
2003-08-22 16:39 ` David S. Miller
2003-08-22 17:41 ` Matthew Wilcox
2003-08-22 17:36 ` David S. Miller
2003-08-22 18:01 ` David S. Miller
2003-08-22 18:34 ` Hugh Dickins
2003-08-22 18:31 ` David S. Miller
2003-08-22 18:56 ` James Bottomley
2003-08-22 19:19 ` David S. Miller
2003-08-22 22:27 ` James Bottomley
2003-08-22 22:41 ` David S. Miller
2003-08-23 1:09 ` James Bottomley
2003-08-23 7:22 ` Hugh Dickins
2003-08-23 15:59 ` James Bottomley
2003-08-23 21:44 ` David S. Miller
2003-08-23 21:43 ` David S. Miller
2003-08-23 22:21 ` James Bottomley
2003-08-23 22:51 ` David S. Miller
2003-08-23 23:01 ` James Bottomley
2003-08-23 22:53 ` David S. Miller
2003-08-23 23:11 ` James Bottomley
2003-08-24 0:22 ` David S. Miller
[not found] ` <1061702282.1992.1153.camel@mulgrave>
[not found] ` <20030823222300.4695a0c4.davem@redhat.com>
2003-08-24 16:54 ` James Bottomley [this message]
2003-08-22 18:41 ` James Bottomley
2003-08-22 19:02 ` Hugh Dickins
2003-08-22 19:09 ` Randolph Chung
2003-08-22 16:42 ` Russell King
2003-08-22 16:39 ` David S. Miller
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=1061744042.13315.29.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=davem@redhat.com \
--cc=drepper@redhat.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=parisc-linux@lists.parisc-linux.org \
--cc=willy@debian.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