HyperSPARC RT625 Cache Controler, Ross CY7C605 Cache Controler,
Hi Dave, Andrew, Sparc Linux Folks:
I'm wondering about the support in Linux for systems with caches that require that
the kernel prevent cache aliases from getting dirty at the same time.
I get the impression that Sun's convention at the time was that the kernel prevented
cache aliases from occurring. Interesting the hardware for Ross CY7C605 appears to have
both virtual and physical cache tags and cache controller appears to update the virtual
cache tags in the event that a snoop detects a cache alias. The 605 seemed to have an additional advantage of being able to process snoops in parallel with the normal cache request from the processor. I thought it seemed like a reasonable thing to do and it would prevent the kernel from having to deal with cache aliases.
Looks like the later HyperSPARC, the RT625, dropped the virtual cache tags and relied on the kernel to prevent cache aliases. It was a later design
and wonder what the cache aliasing correction support was removed.
We have a non-SMP chip that doesn't handle cache aliases in the hardware and are coming out with a SMP processor soon. I was wondering if adding the 605 features of detecting aliases during while snooping and correcting them would be a worthwhile effort and the consequences in the Linux kernel to having to deal with this; especially and new SMP issues.
I noticed that some of the sparc MMU code had support for coloring in a mm hyperSPARC file, but it seemed to be related to DMA. In our current code we do
cache flushes in the user copy code for copies that would cause dirty aliases cache
lines and have additional code like pte_alloc_one_kernel() in arch/xtensa/mm/pgtable.c
which keeps allocating pages until it gets one with a compatible color. I haven't seen anything odd like this in the SPARC mm code yet. How does the Linux SPARC code deal with cache coloring support for Sun4m?
Since it appears that at least the HyperSPARC 605 shared this dependency on the kernel I thought I might find some insight into the cost and mechanisms used to support this in an SMP environment. I thought you, Andrew, or others on the sparc mailing list
might have some thoughts and recommendations that you wouldn't mind
sharing when it's convenient.
-piet
Re: HyperSPARC RT625 Cache Controler, Ross CY7C605 Cache
From: Piet Delaney <[email protected]>
Date: Thu, 28 Aug 2008 02:29:44 -0700
Quoted 9 lines
I noticed that some of the sparc MMU code had support for coloring in a mm hyperSPARC file, but it seemed to be related to DMA. In our current code we do cache flushes in the user copy code for copies that would cause dirty aliases cache lines and have additional code like
pte_alloc_one_kernel()inarch/xtensa/mm/pgtable.cwhich keeps allocating pages until it gets one with a compatible color. I haven't seen anything odd like this in the SPARC mm code yet. How does the Linux SPARC code deal with cache coloring support for Sun4m?
It handles it by:
1) Enforcing a mmap() shared writable memory boundary equal to the L2 cache size.
2) When colors cannot avoid being violated, we flush the cache.
It's extremely expensive, especially on SMP. And #2 happens a lot because we access user mapped pages on the kernel side using a fixed linear mapping and thus a fixed color, and that color often conflicts with the virtual address userspace is using for the same page, so we have to cache flush.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: HyperSPARC RT625 Cache Controler, Ross CY7C605 Cache Controler, Cache Aliases, and Linux MM Code
From: Piet Delaney <[email protected]>
Date: Mon, 08 Sep 2008 22:07:26 -0700
Quoted 2 lines
Wonder why the
update_mmu_cache()for sun4c has to do so much more work that sun4m.
Caches are virtually indexed and virtually tagged on sun4c, that's why.
Keep on wonderin'
Quoted 1 line
Wonder why SPARC has to do more work that ARM.
ARMs that have the cache issues aren't SMP, that's why.
Keep on wonderin'