linux-mips
[Top] [All Lists]

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

To: "David VomLehn" <dvomlehn@cisco.com>
Subject: Re: Anyone noticed that there are a lot of cache flushes after kunmap/kunmap_atomic is called?
From: "Jon Fraser" <jfraser@broadcom.com>
Date: Mon, 11 Aug 2008 20:49:08 -0400
Cc: "Ralf Baechle" <ralf@linux-mips.org>, linux-mips@linux-mips.org, michael.sundius@sciatl.com
In-reply-to: <48A0C8E7.6080506@cisco.com>
Organization: Broadcom
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <489A5975.1000401@cisco.com> <20080808082404.GA27519@linux-mips.org> <1218206499.20791.152.camel@chaos.ne.broadcom.com> <48A0C8E7.6080506@cisco.com>
Reply-to: jfraser@broadcom.com
Sender: linux-mips-bounce@linux-mips.org
David,

I agree.  It's my number one work item this week.  Well,
so far, anyway :-)

Jon


On Mon, 2008-08-11 at 16:19 -0700, David VomLehn wrote:
> Jon Fraser wrote:
> > David,
> > 
> >   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.
> 
> As I understand it, you have the most difficult combination of things:
> o You are using high memory
> o You have a virtually indexed cache
> o You have data cache aliases
> 
> Fortunately, we have only the first two of those in our system. We should 
> probably put together a coherent set of patches for people who want high 
> memory. 
> So far as I can tell, the 32-bit MIPS architecture has a long way to go 
> before it 
> runs out of steam in the embedded world. I expect more people will need MIPS 
> highmem support in the next few years.
> 
> David
> 
> 



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