Editing CPU cache (section)

===Page coloring===
{{Main article|Cache coloring}}

Large physically indexed caches (usually secondary caches) run into a problem: the operating system rather than the application controls which pages collide with one another in the cache. Differences in page allocation from one program run to the next lead to differences in the cache collision patterns, which can lead to very large differences in program performance. These differences can make it very difficult to get a consistent and repeatable timing for a benchmark run.

To understand the problem, consider a CPU with a 1&nbsp;MiB physically indexed direct-mapped level-2 cache and 4&nbsp;KiB virtual memory pages. Sequential physical pages map to sequential locations in the cache until after 256 pages the pattern wraps around. We can label each physical page with a color of 0–255 to denote where in the cache it can go. Locations within physical pages with different colors cannot conflict in the cache.

Programmers attempting to make maximum use of the cache may arrange their programs' access patterns so that only 1&nbsp;MiB of data need be cached at any given time, thus avoiding capacity misses. But they should also ensure that the access patterns do not have conflict misses. One way to think about this problem is to divide up the virtual pages the program uses and assign them virtual colors in the same way as physical colors were assigned to physical pages before. Programmers can then arrange the access patterns of their code so that no two pages with the same virtual color are in use at the same time. There is a wide literature on such optimizations (e.g. [[loop nest optimization]]), largely coming from the [[High Performance Computing|High Performance Computing (HPC)]] community.

The snag is that while all the pages in use at any given moment may have different virtual colors, some may have the same physical colors. In fact, if the operating system assigns physical pages to virtual pages randomly and uniformly, it is extremely likely that some pages will have the same physical color, and then locations from those pages will collide in the cache (this is the [[birthday paradox]]).

The solution is to have the operating system attempt to assign different physical color pages to different virtual colors, a technique called ''page coloring''. Although the actual mapping from virtual to physical color is irrelevant to system performance, odd mappings are difficult to keep track of and have little benefit, so most approaches to page coloring simply try to keep physical and virtual page colors the same.

If the operating system can guarantee that each physical page maps to only one virtual color, then there are no virtual aliases, and the processor can use virtually indexed caches with no need for extra virtual alias probes during miss handling. Alternatively, the OS can flush a page from the cache whenever it changes from one virtual color to another. As mentioned above, this approach was used for some early SPARC and RS/6000 designs.

The software page coloring technique has been used to effectively partition the shared Last level Cache (LLC) in multicore processors.<ref>{{Cite conference |last1=Lin |first1=Jiang |last2=Lu |first2=Qingda |last3=Ding |first3=Xiaoning |last4=Zhang |first4=Zhao |last5=Zhang |first5=Xiaodong |last6=Sadayappan |first6=P. |date=2008 |title=Gaining insights into multicore cache partitioning: Bridging the gap between simulation and real systems |conference=IEEE 14th International Symposium on High Performance Computer Architecture |location=Salt Lake City, Utah |pages=367–378 |doi=10.1109/HPCA.2008.4658653}}</ref> This operating system-based LLC management in multicore processors has been adopted by Intel.<ref>{{Cite web|url=http://web.cse.ohio-state.edu/~zhang.574/OS-cache-software_intel_2010.pdf|title=Letter to Jiang Lin}}</ref>