Re: Cache Aliasing

["David S. Miller" <davem@davemloft.net>]

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."