From: Ralf Baechle <ralf@linux-mips.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: David Miller <davem@davemloft.net>,
nickpiggin@yahoo.com.au, akpm@osdl.org,
linux-kernel@vger.kernel.org, anemo@mba.ocn.ne.jp,
linux-arch@vger.kernel.org, schwidefsky@de.ibm.com,
James.Bottomley@SteelEye.com
Subject: Re: [PATCH 1/3] Fix COW D-cache aliasing on fork
Date: Sat, 21 Oct 2006 01:06:09 +0100 [thread overview]
Message-ID: <20061021000609.GA32701@linux-mips.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0610201625190.3962@g5.osdl.org>
On Fri, Oct 20, 2006 at 04:28:37PM -0700, Linus Torvalds wrote:
> > > My understanding is that this works because in Ralf's original patch
> > > (which is the context in which he is removing the flush_cache_mm()
> > > call), he uses kmap()/kunmap() to map the page(s) being accessed at a
> > > kernel virtual address which will fall into the same cache color as
> > > the user virtual address --> no alias problems.
> > >
> > > Since he does this for every page touched on the kernel side during
> > > dup_mmap(), the existing flush_cache_mm() call in dup_mmap() does in
> > > fact become redundant.
> >
> > Correct.
> >
> > It means no cache flush operation to deal with aliases at all left in
> > fork and COW code.
>
> Umm. That would seem to only happen to work for a direct-mapped virtually
> indexed cache where the index is taken purely from the virtual address,
> and there are no "process context" bits in the virtually indexed D$.
No MIPS processor has something like that. See below.
> The moment there are process context bits involved, afaik you absolutely
> _need_ to flush, because otherwise the other process will never pick up
> the dirty state (which it would need to reload from memory).
Correct.
> That said, maybe nobody does that. Virtual caches are a total braindamage
> in the first place, so hopefully they have limited use.
On MIPS we never had pure virtual caches. The major variants in existence
are:
o D-cache PIPT, I-cache PIPT
o PIVT (no typo!)
Only the R6000 has this and it's not supported by Linux.
o D-cache VIPT, I-cache VIPT
This is by far the most common on any MIPS designed since '91.
A variant of these caches has hardware logic to detect cache aliases and
fix them automatically and therefore is equivalent to PIPT even though
they are not implemented as PIPT. And obviously the alias replay of the
pipe will cost a few cycles. The R10000 family of SGI belongs into this
class and the 24K/34K family of synthesizable cores by MIPS Technologies
have this as a synthesis option.
Another variant throws virtual coherency exceptions as I've explained in
another thread.
o D-cache PIPT, I-cache VIVT with additional address space tags.
o Cacheless. Not usually running Linux but heck, it's working anyway.
Be sure I'm sending a CPU designers a strong message about aliases. And I
think they're slowly getting the message that kernel hackers like to poke
needles into voodoo dolls for aliases ;-)
Ralf
next prev parent reply other threads:[~2006-10-21 0:06 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-19 16:35 [PATCH 1/3] Fix COW D-cache aliasing on fork Ralf Baechle
2006-10-19 16:35 ` [PATCH 2/3] Pass vma argument to copy_user_highpage() Ralf Baechle
2006-10-19 16:35 ` [PATCH 3/3] MIPS: Fix COW D-cache aliasing on fork Ralf Baechle
2006-10-22 2:32 ` Ralf Baechle
2006-10-19 17:46 ` [PATCH 1/3] " Nick Piggin
2006-10-19 18:13 ` Ralf Baechle
2006-10-19 18:48 ` Nick Piggin
2006-10-19 22:59 ` David Miller
2006-10-20 14:39 ` Nick Piggin
2006-10-20 15:49 ` Linus Torvalds
2006-10-20 15:57 ` Nick Piggin
2006-10-20 16:36 ` Linus Torvalds
2006-10-20 16:47 ` Nick Piggin
2006-10-20 17:16 ` Linus Torvalds
2006-10-20 17:37 ` Nick Piggin
2006-10-21 0:46 ` Ralf Baechle
2006-10-20 19:36 ` David Miller
2006-10-20 19:54 ` Linus Torvalds
2006-10-20 19:58 ` David Miller
2006-10-20 20:10 ` Linus Torvalds
2006-10-20 20:59 ` Russell King
2006-10-20 21:06 ` David Miller
2006-10-20 21:17 ` Russell King
2006-10-20 21:30 ` David Miller
2006-10-20 21:12 ` Linus Torvalds
2006-10-20 21:28 ` Russell King
2006-10-20 21:41 ` Ralf Baechle
2006-10-21 16:28 ` Atsushi Nemoto
2006-10-20 21:49 ` Ralf Baechle
2006-10-20 22:02 ` Linus Torvalds
2006-10-20 22:22 ` David Miller
2006-10-20 22:51 ` Ralf Baechle
2006-10-20 23:28 ` Linus Torvalds
2006-10-21 0:06 ` Ralf Baechle [this message]
2006-10-21 0:38 ` Linus Torvalds
2006-10-21 1:29 ` Paul Mackerras
2006-10-21 2:11 ` David Miller
2006-10-21 2:37 ` Linus Torvalds
2006-10-21 2:46 ` David Miller
2006-10-21 18:27 ` Ralf Baechle
2006-10-22 1:34 ` Ralf Baechle
2006-12-02 9:49 ` Russell King
2006-10-23 8:50 ` Martin Schwidefsky
2006-10-20 16:05 ` Ralf Baechle
2006-10-20 16:30 ` Nick Piggin
2006-10-20 19:23 ` David 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=20061021000609.GA32701@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=James.Bottomley@SteelEye.com \
--cc=akpm@osdl.org \
--cc=anemo@mba.ocn.ne.jp \
--cc=davem@davemloft.net \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=schwidefsky@de.ibm.com \
--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