topic So as I understood there is in Software Tuning, Performance Optimization & Platform Monitoring

Time based cache eviction

Michal_C_1 — Wed, 12 Jun 2013 13:05:45 GMT

Hi everyone,

Can someone please say whether the Xeon E5-2670 has a cache eviction logic which operates solely based on time, that is, suppose we don't try to load any new memory into the processor, will data residing in any cache level, which is older than a certain time, still be evicted?

Also, does anyone know if there exists a document which provides any sort of details on the factors affecting cache management for the above processor?

>>...Also, does anyone know

SergeyKostrov — Wed, 12 Jun 2013 13:57:00 GMT

>>...Also, does anyone know if there exists a document which provides any sort of details on the factors affecting cache >>management for the above processor? Please take a look at: - Intel® 64 and IA-32 Architectures Software Developer’s Manual ( June 2013 Edition ) and - A Datasheet for the CPU on ark.intel.com ( All Datasheets have lots of technical details specific to CPUs )

Hello Michael,

Patrick_F_Intel1 — Wed, 12 Jun 2013 14:29:24 GMT

Hello Michael,

There isn't an eviction policy based on time exactly but, if the cpu goes idle and the core or package (all the cores) go into c-states then caches may be flushed... depending on the c-state level.

The SDM probably covers this in detail... probably in vol3 some chapter on power management.

Here are a couple of power management overviews.

http://www.hotchips.org/wp-content/uploads/hc_archives/hc23/HC23.19.9-Desktop-CPUs/HC23.19.921.SandyBridge_Power_10-Rotem-Intel.pdf . see slide 22 particular.

www.cs.pitt.edu/~kirk/cs3150spring2010/ShiminChen.pptx‎ is a general power management intro.

Also, the cache replacement policy is called 'pseudo-least-recently-used', not 'truly least recently used'. So sometimes a cache line will be evicted when another cache line is actually less used. And then there is stuff the OS might do or other tasks that might run that could evict data. And things like snoops from other processors (if you have more than 1 socket) or even memory scrubbing (see wikipedia 'memory scrubbing') to unexpectedly memory traffic.

What are you trying to accomplish?

Pat

So as I understood there is

Bernard — Wed, 12 Jun 2013 15:04:42 GMT

So as I understood there is no any aging timer related to maintaining old data/instructions in cache.It is interesting how algorithm implements or measure "frequency of usage"?I think about some kind of counter which will be incremented when there is more references to some data.

Hi Patrick,

Michal_C_1 — Wed, 12 Jun 2013 15:14:34 GMT

Hi Patrick,

Thank you for the answer. I was just trying to determine if there is a set maximum time for which process does not have to touch data and can still hit the data in cache assuming no other processes evict the line. It seems that no such maximum time exists then.

Michal

>>...The SDM probably covers

SergeyKostrov — Fri, 14 Jun 2013 05:21:59 GMT

>>...The SDM probably covers this in detail... probably in vol3 some chapter on power management... Here is some statistics for several search expressions: 'time based cache eviction' - No any references 'cache eviction' - 2 references 'eviction' - lots of references with detailed technical inofrmation I checked All Volumes of Intel SDM.

Time-based eviction is pretty

McCalpinJohn — Mon, 24 Jun 2013 19:44:58 GMT

Time-based eviction is pretty clearly not a documented feature of Intel processors.

The only time I have run across time-based eviction was in SGI's IRIX for MIPS-based systems in the late 1990's. IIRC, at every 10 millisecond timer interrupt, a pair of TLB entries were invalidated (by index, in a round-robin fashion) on each processor. Since there were 64 pairs of TLB entries, you were guaranteed that no TLB entries in the system were more than 640 milliseconds old. This was useful in some aspects of memory free list handling. (Details left as an exercise for the reader.)

Maybe invalidated TLB entries

Bernard — Tue, 25 Jun 2013 05:46:36 GMT

Maybe invalidated TLB entries pointed to freed addresses?