Cache Aliasing

Cache Aliasing

[Chris Zankel]

Hi,

I am stuck trying to figure out why the sparc64 implementation for cache 
aliasing actually works:

 From my understanding, any kernel (or driver) function can 
allocate/free pages with __page_alloc() / free_page(). I couldn't find 
any place, however, where the cache is flushed in either case, so there 
might be some residue in the cache.

During allocation of user pages, the sparc64 implementation might 
temporarily map that page to a cache-coherent location (TLBTEMP_BASE+x) 
for {clear|copy}_user_page. At that time, however, couldn't there  still 
be dirty lines in the other 'half' of the cache from the previous kernel 
allocation?

I'd appreciate any direction where I could find more information about 
this scenario or where I should look in the kernel code.

Thanks,
-Chris

Re: Cache Aliasing

[David S. Miller]

From: Chris Zankel <chris@zankel.net>
Date: Thu, 16 Mar 2006 12:38:37 -0800

> I am stuck trying to figure out why the sparc64 implementation for cache 
> aliasing actually works:
> 
>  From my understanding, any kernel (or driver) function can 
> allocate/free pages with __page_alloc() / free_page(). I couldn't find 
> any place, however, where the cache is flushed in either case, so there 
> might be some residue in the cache.
> 
> During allocation of user pages, the sparc64 implementation might 
> temporarily map that page to a cache-coherent location (TLBTEMP_BASE+x) 
> for {clear|copy}_user_page. At that time, however, couldn't there  still 
> be dirty lines in the other 'half' of the cache from the previous kernel 
> allocation?

It doesn't matter, the user and the kernel never access the other
alias, since the are accessing the page using only that particular
color.

> I'd appreciate any direction where I could find more information about 
> this scenario or where I should look in the kernel code.

When you initially allocate a page, you make stores to initialize
it's contents, so aliasing doesn't matter from the perspective.
The stores will show up in the correct mappings in the D-cache.

The UltraSPARC programmer's reference manual even states this
explicitly: "A change in virtual color when allocating a free
page does not require a D-cache flush because the D-cache is
write-through."

Cache aliasing

[John Newlin]

I'm working on a port of Linux to a processor that has virutally
indexed caches that are larger than the page size.  This brings up
the documented feature of cache aliasing.

As I am looking over how other ports (sh-4, sparc64 etc) have solved
the problem, it made me wonder if this is the best way to solve
the problem.

Would it make more sense to just always ensure that your 
virtual and physical pages had matching "color" bits?

For example, in the memory allocator, you would have to pass in
the vaddr that you wanted to map to physical space, and then the
memory allocator would find a physical page of the correct color.

And in the case where you are mirroring a user page into kernel
space, you would have to choose a virtual address of the correct
colour.  On architectures like x86 where cache aliasing is never
a concern, this code could be optimized away.


The benefits would be, any architecture that has cache aliasing
wouldn't have to go through hoops to keep memory coherent, and
depending on how often memory is flushed in the caches it might
give some performance boost.



-John 

Re: Cache aliasing

[David S. Miller]

On Mon, 2003-02-24 at 23:24, John Newlin wrote:
> Would it make more sense to just always ensure that your 
> virtual and physical pages had matching "color" bits?

No, it's actually very difficult to solve the problem this
way.

The reason being that there is always a fixed "kernel virtual
color" every physical page has.  So essentially, if you colored
userspace, you could only put into user virtual address with
color X only pages that also have kernel virtual color X.