[Top] [All Lists]

Re: Anyone noticed that there are a lot of cache flushes after kunmap/ku

To: "Ralf Baechle" <>
Subject: Re: Anyone noticed that there are a lot of cache flushes after kunmap/kunmap_atomic is called?
From: "Jon Fraser" <>
Date: Fri, 08 Aug 2008 10:41:39 -0400
Cc: "David VomLehn" <>, "" <>
In-reply-to: <>
Organization: Broadcom
Original-recipient: rfc822;
References: <> <>

  I'm battling this now.  Our mips 24k has a virtually indexed cache.
We're definitely seeing issues where the cache hasn't been flushed
for highmem pages.  I thought I had this fixed, but I'm still seeing
some problems.


On Fri, 2008-08-08 at 09:24 +0100, Ralf Baechle wrote:
> On Wed, Aug 06, 2008 at 07:09:57PM -0700, David VomLehn wrote:
> > On the MIPS processor, cache flushing is done based on virtual addresses. 
> > However, in the Linux kernel, there are a lot of places where memory is 
> > mapped with kmap or kmap_atomic, then unmapped with the corresponding 
> > kunmap or kunmap_atomic and only *then* is the cache flushed. In other 
> > words, we only flush the cache after we have dropped the mapping of 
> > memory into a virtual address. I think this is generally wrong.
> >
> > This may really only affect those of us who have enabled high memory, but 
> > it's pretty prevalent in kernel code. We noted this before, but have 
> > apparently just been bitten by it. Is it just me or is there a fairly 
> > widespread problem for processors that flush the cache using virtual 
> > addresses?
> Not all MIPS processors have virtually indexed caches; some have physically
> indexed caches or caches which behave effectivly like physically indexed
> and MIPS highmem only tries to support the latter kinds of caches.  Which
> means most of the cache flushes turn into nops anyway.
>   Ralf

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