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."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
