Re: Fwd: Re: flush_cache_page()

[Ralf Baechle]

On Sat, Jan 29, 2005 at 08:29:22AM -0600, James Bottomley wrote:

> On Sat, 2005-01-29 at 11:37 +0000, Russell King wrote:
> > Thanks for the response.  However, apart from Ralph, Paul and yourself,

Who are you talking about ;-)

> > it seems none of the other architecture maintainers care about this
> > patch - the original mail was BCC'd to the architecture list.  Maybe
> > that's an implicit acceptance of this patch, I don't know.
> 
> Well, OK, I'll try to answer for parisc, since we have huge VIPT
> aliasing caches as well.
> 
> Right now, we have a scheme in flush_cache_page to make sure it's only
> called when necessary (cache flushes are expensive for us and show up as
> the primary cpu consumer in all of our profiles).  Our scheme is to see
> if a translation exists for the page and skip the flush if it doesn't.
> 
> Obviously, like MIPS, we're also walking the page tables without
> locking...

VIPT caches on MIPS R4000-class processors will perform an address
translation using the TLB to obtain the physical address that will be
compared against the cache tags.  This may result in TLB reloads which are
an ugly case to deal with if the flush is being performed for a mm other
than current->mm.  Since a long time the flush_cache_page implementation
assumes getting this right is too hard but I suppose it's an optimization
that should be attempted and which would require pagetable lookups.

The current implementation actually does lookups as an optimization (and
I'm just asking myself if that is still correct) by looking at the present
bit of the pte to deciede if data from that page may have entered the cache
at all so we can avoid the flush entirely.

> Looking at the callers of this, it seems it would be very unlikely to
> call this with a missing translation, in that case, we can use the pfn
> to flush the page through a temporary alias space instead and just take
> the odd hit if no translation exists.  

That would be the MIPS optimization for the case of flushing on behalf of
another process.

  Ralf

PS: Don't get me started on PIVT caches ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/