From: James Bottomley <James.Bottomley@steeleye.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: Linus Torvalds <torvalds@osdl.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] fix remap of shared read only mappings
Date: 04 Sep 2003 19:23:46 -0400 [thread overview]
Message-ID: <1062717828.2161.449.camel@mulgrave> (raw)
In-Reply-To: <20030904225636.GN31590@mail.jlokier.co.uk>
On Thu, 2003-09-04 at 18:56, Jamie Lokier wrote:
> You have just argued _against_ worrying about cache coherence by
> aligning mapping addresses.
>
> Basically, POSIX says shared mappings aren't guanteed to be coherent
> until you call msync(). Then you can just do whatever is needed to
> make different views coherent. That's easier now that we have rmap.
I think you may misunderstand what I mean by coherence: Our problem is
the VIVT processor caches. Once one mapper does an msync, that data
must be visible to all the other mappers, so at that point we have to
flush the cache lines of all the other mappers. On PA, we only need to
flush one correctly aligned address to get the VIVT cache to flush all
the others. However, the kernel page cache usually holds an unaligned
reference so we need to do the extra aligned flush when this data
changes. If we didn't do the alignment, we'd need to flush every
virtual address in the current CPU translation for that page.
If you mean PROT_SEM requires immediate coherence without an msync, then
those semantics would be very tricky to achieve on parisc since we'd
need the kernel virtual address of the page in the page cache correctly
aligned as well.
rmap isn't really necessary for this, that's what the
page->mapping->i_mmap and i_mmap_shared lists are for.
James
next prev parent reply other threads:[~2003-09-04 23:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-04 14:49 [PATCH] fix remap of shared read only mappings James Bottomley
2003-09-04 21:48 ` Jamie Lokier
2003-09-04 22:33 ` James Bottomley
2003-09-04 22:56 ` Jamie Lokier
2003-09-04 23:23 ` James Bottomley [this message]
2003-09-04 23:40 ` Jamie Lokier
2003-09-05 0:49 ` Daniel Phillips
2003-09-05 0:49 ` Linus Torvalds
2003-09-05 1:07 ` Alan Cox
2003-09-05 1:31 ` Daniel Phillips
2003-09-05 4:35 ` Linus Torvalds
2003-09-05 0:52 ` James Bottomley
2003-09-05 1:21 ` Daniel Phillips
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=1062717828.2161.449.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=jamie@shareable.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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