linux-mips
[Top] [All Lists]

Re: flush_anon_page for MIPS

To: Franck Bui-Huu <vagabon.xyz@gmail.com>
Subject: Re: flush_anon_page for MIPS
From: Ralf Baechle <ralf@linux-mips.org>
Date: Fri, 23 Mar 2007 15:20:01 +0000
Cc: Miklos Szeredi <miklos@szeredi.hu>, linux-mips@linux-mips.org, Ravi.Pratap@hillcrestlabs.com
In-reply-to: <cda58cb80703230747w524409d7m3ee7753e676b0683@mail.gmail.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <E1HUVlw-00034H-00@dorka.pomaz.szeredi.hu> <20070323141939.GB17311@linux-mips.org> <cda58cb80703230747w524409d7m3ee7753e676b0683@mail.gmail.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4.2.2i
On Fri, Mar 23, 2007 at 03:47:45PM +0100, Franck Bui-Huu wrote:

> On 3/23/07, Ralf Baechle <ralf@linux-mips.org> wrote:
> >The other thing I still need to understand is why nobody actually seems
> >to have triggered this bug on MIPS so far.  I suppose our implementation
> >of flush_dcache_page() may have done a successful job at papering it
> >which means there might be some performance getting lost there as well.
> >
> 
> Just to understand, doesn't all mappings of shared anonymous pages and
> kernel addresses of them share the same cache lines ?

That's true only for all userspace mappings and an anonymous page should
normally have only a single mapping per mm anyway.  But to make things
more complicated a page of course also has a kernel space address in
KSEG0 or XKPHYS and on a VIPT cache there we frequently have the case
where the user address and the kernel address would map to a different
cache line.

Let me illustrate this with a little example.  Assume we have a page at
physical address 0x5000, a page size of 4kB, an 8kB direct mapped cache
and 32-byte cache lines.  Then address bits 0..4 will be the byte index
into the cache line, address bits 5..12 will index the cache array.  So
now let's map our page into userspace, at address 0x12340000.  In KSEG0
it is accessible at 0x80005000.  Now, compute the cache index for both
addresses compare and curse ...

  Ralf

<Prev in Thread] Current Thread [Next in Thread>