4

What happens to dirty cache lines which are not yet written back (assuming write-back cache), when the page it is part of is chosen for eviction by the Operating System. In other words what happens to the cache lines of the page, when a page is chosen for eviction from main memory.

The general assumption is that by the time the page is evicted from memory it is cold enough not to be cached. However would this pose a problem in larger caches? If say we have enough cache lines to fit 1 line from each page?

adarshpatil
  • 41
  • 5
  • Interesting point. There's an issue because memory is copied to disk by DMA from main memory, and doesn't have access to the CPU's caches. Wikipedia's DMA article [mentions this issue](https://en.wikipedia.org/wiki/Direct_memory_access#Cache_coherency). Another SO question asked about this, for x86 hardware. http://stackoverflow.com/questions/7132284/dma-cache-coherence-management. Apparently hardware can/does have DMA cache snooping these days. The memory controllers in modern CPUs are built-in to the CPU core, so it's not too hard for them to check the cache. – Peter Cordes Nov 14 '15 at 06:14
  • I got a lot of hits googling on `linux dma cache coherence`, so try that. – Peter Cordes Nov 14 '15 at 06:19

1 Answers1

0

Nothing will directly happen to the cache lines. In an operating system, we must always assume the worse of the possibilities, and even small caches could face your proposed scenario. However, the operating system does not need to do anything directly to the cache lines, the normal process of paging will handle this scenario.

When the operating system decides to evict a page, it will first write its contents out to disk (as the processor would have marked the page table entry as dirty indicating that the page has been written to). In the process of doing so, the OS will read the values from the entire page including the dirty cache lines, so they will be written back, at least to disk.

Next as part of evicting the page, the operating system will invalidate the translations that map the virtual to physical addresses. Even if the cache lines are still dirty, they can no longer be accessed by the process (i.e., program). After this step, the operating system will write different data into the physical page, and this action will invalidate the cache lines. Finally, the newly repurposed physical page will be mapped to a virtual address.

Brian
  • 2,693
  • 5
  • 26
  • 27
  • I agree that the OS does not need to do anything to cache lines as they are hardware managed. However, when the DMA controller writes the memory page to disk the latest copy for that location must come from the dirty cache line. This would suggest that the DMA controller has bus to access cache lines. Is that how it works from the hardware perspective? – adarshpatil Nov 13 '15 at 07:38
  • 1
    @adarshpatil I guess, WBINVD would help in this case? – Alexey Frunze Nov 13 '15 at 08:53
  • @AlexeyFrunze: it seems there is DMA cache snooping these days, but before that you'd want to loop over a page running `CLFLUSH`. `WBINVD` wipes out the *entire* cache, including all 8MiB of shared L3 or whatever size you have, which is *way* too expensive for a modern system with large caches. – Peter Cordes Nov 14 '15 at 06:21
  • @PeterCordes You're right WBINVD would be too expensive. OTOH, I don't remember to ever need to flush caches explicitly on the x86 PC. It looks like for most cases (starting with the 80486 because the 80386 didn't have internal caches) cache snooping and the chipset do this for you automagically. – Alexey Frunze Nov 14 '15 at 23:22
  • @Brian: When you [review first-posts](http://meta.stackoverflow.com/questions/288505/how-should-i-get-started-reviewing-late-answers-and-first-posts), *please* correct the tags, and remember that's a one-shot queue, so be more willing to skip: http://stackoverflow.com/posts/35319533/revisions – Deduplicator Feb 10 '16 at 16:34