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
From: Chris Zankel <[email protected]>
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."