{"id":3073,"date":"2018-11-25T10:44:59","date_gmt":"2018-11-25T10:44:59","guid":{"rendered":"http:\/\/mertboru.com\/?p=3073"},"modified":"2019-05-13T07:51:29","modified_gmt":"2019-05-13T07:51:29","slug":"taming-a-beast-cache","status":"publish","type":"post","link":"http:\/\/mertboru.com\/?p=3073","title":{"rendered":"Taming a Beast: CPU Cache"},"content":{"rendered":"

(Cover Photo:\u00a0 \u00a9 Granger – “Lion Tamer”<\/em><\/span>
\nThe American animal tamer Clyde Beatty<\/em><\/span>
\nperforming in the 1930s.)<\/em><\/span><\/p>\n

The processor’s caches are for the most part transparent to software. When enabled, instructions and data flow through these caches without the need for explicit software control. However, knowledge of the behavior of these caches may be useful in optimizing software performance. If not tamed wisely, these innocent cache mechanisms can certainly be a headache for novice C\/C++ programmers.<\/strong><\/p>\n

First things first\u2026 Before I start with example C\/C++ codes showing some common pitfalls and urban caching myths that lead to hard-to-trace bugs, I would like to make sure that we are all comfortable with ‘cache related terms’<\/em>.<\/p>\n

\"\"<\/p>\n

Terminology<\/strong><\/p>\n

In theory, CPU cache<\/strong> is a very high speed type of memory<\/em> that is placed between the CPU and the main memory. (In practice, it is actually inside<\/em> the processor, mostly operating at the speed of the CPU.) In order to improve latency of fetching information from the main memory, cache stores some of the information temporarily so that the next access to the same chunk of information is faster. CPU cache can store both ‘executable instructions’<\/strong><\/em><\/span> and ‘raw data’<\/strong><\/em><\/span>.<\/p>\n

\n

“… from cache, instead of going back to memory.”<\/strong><\/p>\n<\/blockquote>\n

When the processor recognizes that an information being read from memory is cacheable, the processor reads an entire cache line into the appropriate cache slot (L1, L2, L3, or all). This operation is called a cache line fill<\/strong>. If the memory location containing that information is still cached when the processor attempts to access to it again, the processor can read that information from the cache instead of going back to memory. This operation is called a cache hit<\/strong>.<\/p>\n

\"\"<\/a>
Hierarchical Cache Structure of the Intel Core i7 Processors<\/figcaption><\/figure>\n

When the processor attempts to write an information to a cacheable area of memory, it first checks if a cache line for that memory location exists in the cache. If a valid cache line does exist, the processor (depending on the write policy currently in force) can write that information into the cache instead of writing it out to system memory. This operation is called a write hit<\/strong>. If a write misses the cache (that is, a valid cache line is not present for area of memory being written to), the processor performs a cache line fill, write allocation<\/strong>. Then it writes the information into the cache line and (depending on the write policy currently in force) can also write it out to memory. If the information is to be written out to memory, it is written first into the store buffer, and then written from the store buffer to memory when the system bus is available.<\/p>\n

\n

“… cached in shared state, between multiple CPUs.”<\/strong><\/p>\n<\/blockquote>\n

When operating in a multi-processor system<\/strong>, The Intel 64 and IA-32 architectures have the ability to keep their internal caches consistent both with system memory and with the caches in other processors on the bus. For example, if one processor detects that another processor intends to write to a memory location that it currently has cached in shared state, the processor in charge will invalidate its cache line forcing it to perform a cache line fill the next time it accesses the same memory location. This type of internal communication between the CPUs is called snooping<\/strong>.<\/p>\n

And finally, translation lookaside buffer (TLB)<\/strong> is a special type of cache designed for speeding up address translation for virtual memory related operations. It is a part of the chip\u2019s memory-management unit (MMU). TLB keeps track of where virtual pages are stored in physical memory, thus speeds up ‘virtual address to physical address’ translation by storing a lookup page-table.<\/p>\n

So far so good… Let’s start coding, and shed some light on urban caching myths. \ud83d\ude09<\/p>\n

 <\/p>\n

\"\"<\/p>\n

 <\/p>\n

How to Guarantee Caching in C\/C++<\/strong><\/p>\n

To be honest, under normal conditions, there is absolutely no way to guarantee that the variable you defined in C\/C++ will be cached. CPU cache and write buffer management are out of scope of the C\/C++ language, actually.<\/p>\n

Most programmers assume that declaring a variable as constant will automatically turn it into something<\/em> cacheable!<\/p>\n

const int nVar = 33;<\/pre>\n
As a matter of fact, doing so will tell the C\/C++ compiler that it is forbidden for the rest of the code to modify the variable’s value, which may or may not<\/span><\/em><\/strong> lead to a cacheable case. By using a const<\/strong>, you simply increase the chance of getting it cached. In most cases, compiler will be able to turn it into a cache hit. However, we can never be sure about it unless we debug and trace the variable with our own eyes.<\/p>\n
 <\/p>\n
\"\"<\/p>\n
 <\/p>\n
How to Guarantee No Caching in C\/C++<\/strong><\/p>\n
An urban myth states that, by using volatile<\/strong> type qualifier, it is possible to guarantee that a variable can never be cached. In other words, this myth assumes that it might be possible to disable CPU caching features for specific C\/C++ variables in your code!<\/p>\n
volatile int nVar = 33;<\/pre>\n
Actually, defining a variable as volatile<\/strong> prevents compiler from optimizing it, and forces the compiler to always refetch (read once again) the value of that variable from memory. But, this may or may not <\/em><\/span><\/strong>prevent it from caching, as volatile<\/strong> has nothing to do with CPU caches and write buffers, and there is no standard support for these features in C\/C++.<\/p>\n
So, what happens if we declare the same variable without const<\/strong> or volatile<\/strong>?<\/p>\n
int nVar = 33;<\/pre>\n
Well, in most cases, your code will be executed and cached properly. (Still not guaranteed though.) But, one thing for sure… If you write ‘weird’<\/em><\/strong><\/span> code, like the following one, then you are asking for trouble!<\/p>\n
int nVar = 33;\r\nwhile (nVar == 33)\r\n{\r\n\u00a0\u00a0 . . .\r\n}<\/pre>\n
In this case, if the optimization is enabled, C\/C++ compiler may assume that nVar<\/strong> never changes (always set to 33) due to no reference of nVar<\/strong> in loop’s body, so that it can be replaced with true<\/strong> for the sake of optimizing while<\/strong> condition.<\/p>\n
while (true)\r\n{\r\n\u00a0\u00a0 . . .\r\n}<\/pre>\n
A simple volatile<\/strong> type qualifier fixes the problem, actually.<\/p>\n
volatile int nVar = 33;\r\n<\/pre>\n
 <\/p>\n
\"\"<\/p>\n
 <\/p>\n
What about Pointers?<\/strong><\/p>\n
Well, handling pointers is no different than taking care of simple integers.<\/p>\n
Case #1:<\/strong><\/p>\n
Let’s try to evaluate the while<\/strong> case mentioned above once again, but this time with a Pointer.<\/p>\n
int nVar = 33;\r\nint *pVar = (int*) &nVar;\r\nwhile (*pVar)\r\n{\r\n   . . .\r\n}<\/pre>\n
In this case,<\/p>\n
\"\"\u00a0 nVar<\/strong> is declared as an integer with an initial value of 33,
\n\"\"\u00a0 pVar<\/strong> is assigned as a Pointer to nVar<\/strong>,
\n\"\"\u00a0 <\/strong>the value of nVar<\/strong> (33) is gathered using pointer pVar<\/strong>, and this value is used as a conditional statement in while<\/strong> loop.<\/p>\n
On the surface there is nothing wrong with this code, but if aggressive C\/C++ compiler optimizations are enabled, then we might be<\/em><\/strong><\/span> in trouble. – Yes, some compilers are smarter than others!<\/em> \ud83d\ude09<\/p>\n
Due to fact that the value of pointer variable has never been modified and\/or accessed through the while<\/strong> loop, compiler may decide to optimize the frequently called conditional statement of the loop. Instead of fetching *pVar<\/strong> (value of nVar) each time from the memory, compiler might think that keeping this value in a register<\/strong> might be a good idea. This is known as ‘software caching’<\/strong><\/em><\/span>.<\/p>\n
Now, we have two problems here:<\/p>\n
1.)<\/strong> Values in registers<\/strong> are ‘hardware cached’<\/strong><\/em><\/span>. (CPU cache can store both instructions<\/em><\/strong> and data<\/em><\/strong>, remember?) If somehow, software cached value in the register goes out of sync with the original one in memory, the CPU will never be aware of this situation and will keep on caching the old value from hardware cache. – CPU cache vs software cache. What a mess!<\/p>\n
Tip:<\/strong> Is that scenario really possible?! – To be honest, no. During the compilation process, the C\/C++ compiler should be clever enough to foresee that problem, if-and-only-if<\/em><\/span><\/strong>\u00a0*pVar<\/strong> has never been modified in loop’s body. However, as a programmer, it is our responsibility to make sure that compiler should be given ‘properly written code’<\/em><\/strong> with no ambiguous logic\/data treatment. So, instead of keeping our fingers crossed and expecting miracles from the compiler, we should take complete control over the direction of our code. Before making assumptions on how our code will be compiled, we should first make sure that our code is crystal clear.<\/div>\n
2.)<\/strong> Since the value of nVar<\/strong> has never\u00a0been modified, the compiler can even go one step further by assuming that the check against *pVar <\/strong>can be casted to a Boolean value, due to its usage as a conditional statement. As a result of this optimization, the code above might turn into this:<\/p>\n
int nVar = 33;\r\nint *pVar = (int*) &nVar;\r\n\r\nif (*pVar)\r\n{\r\n   while (true)\r\n   {\r\n      . . .\r\n   }\r\n}<\/pre>\n
Both problems detailed above, can be fixed by using a volatile<\/strong> type qualifier. Doing so prevents the compiler from optimizing *pVar<\/strong>, and forces the compiler to always refetch the value from memory, rather than using a compiler-generated software cached<\/strong><\/em><\/span> version in registers.<\/p>\n
int nVar = 33;\r\nvolatile int *pVar = (int*) &nVar;\r\nwhile (*pVar)\r\n{\r\n   . . .\r\n}<\/pre>\n
Case #2:<\/strong><\/p>\n
Here comes an another tricky example about Pointers.<\/p>\n
const int nVar = 33;\r\nint *pVar = (int*) &nVar;\r\n*pVar = 0;<\/pre>\n
In this case,<\/p>\n
\"\"\u00a0 nVar<\/strong> is declared as a ‘constant’<\/em> variable,
\n\"\"\u00a0 pVar<\/strong> is assigned as a Pointer to nVar<\/strong>,
\n\"\"\u00a0 and, pVar<\/strong> is trying to change the ‘constant’<\/em> value of nVar<\/strong>!<\/p>\n
Under normal conditions, no C\/C++ programmer would make such a mistake, but for the sake of clarity let’s assume that we did.<\/p>\n
If aggressive optimization is enabled, due to fact that;<\/p>\n
a.)<\/strong> Pointer variable points to a constant variable,<\/p>\n
b.)<\/strong> Value of pointer variable has never been modified and\/or accessed,<\/p>\n
some compilers may assume that the pointer can be optimized for the sake of software caching<\/em><\/strong><\/span>. So, despite *pVar = 0<\/strong>, the value of nVar<\/strong> may<\/em> never change.<\/p>\n
Is that all? Well, no\u2026 Here comes the worst part! The value of nVar<\/strong> is actually compiler dependent<\/em><\/strong><\/span>. If you compile the code above with a bunch of different C\/C++ compilers, you will notice that in some of them nVar<\/strong> will be set to 0, and in some others set to 33 as a result of ‘ambiguous’<\/em><\/strong><\/span> code compilation\/execution. Why? Simply because, every compiler has its own standards when it comes to generating code for ‘constant’ variables. As a result of this inconsistent situation, even with just a single constant variable, things can easily get very complicated.<\/p>\n
Tip:<\/strong> The best way to fix ‘cache oriented compiler optimization issues’, is to change the way you write code, with respect to tricky compiler specific optimizations in mind. Try to write crystal clear code. Never assume that compiler knows programming better than you. Always debug, trace, and check the output… Be prepared for the unexpected!<\/div>\n
Fixing such brute-force compiler optimization issues is quite easy. You can get rid of const\u00a0<\/strong>type qualifier,<\/p>\n
const<\/del> int nVar = 33;<\/pre>\n
or, replace const<\/strong> with volatile\u00a0<\/strong>type qualifier,<\/p>\n
volatile int nVar = 33;<\/pre>\n
or, use both!<\/p>\n
const volatile int nVar = 33;<\/pre>\n
Tip:<\/strong> ‘const volatile’ combination is commonly used on embedded systems, where hardware registers<\/strong><\/em> that can be read and are updated by the hardware, cannot be altered by software. In such cases, reading hardware register’s value is never cached, always refetched from memory.<\/div>\n
 <\/p>\n
\"\"<\/p>\n
 <\/p>\n
Rule of Thumb<\/strong><\/p>\n
Using volatile<\/strong> is absolutely necessary<\/em><\/span><\/strong> in any situation where compiler could make wrong assumptions about a variable keeping its value constant, just because a function does not change it itself. Not using volatile<\/strong> would create very complicated bugs due to the executed code that behaves as if the value did not change – (It did, indeed)<\/em>.<\/p>\n
If code that works fine, somehow fails when you;<\/p>\n
\"\"\u00a0 Use cross compilers,
\n\"\"\u00a0 Port code to a different compiler,
\n\"\"\u00a0 Enable compiler optimizations,
\n\"\"\u00a0 Enable interrupts,<\/p>\n
make sure that your compiler is NOT over-optimizing variables for the sake of software caching.<\/p>\n
Please keep in mind that, volatile<\/strong> has nothing to do with CPU caches and write buffers, and there is no standard support for these features in C\/C++. These are out of scope of the C\/C++ language, and must be solved by directly interacting with the CPU core!<\/p>\n
 <\/p>\n
\"\"<\/p>\n
 <\/p>\n
Getting Hands Dirty via Low-Level CPU Cache Control<\/strong><\/p>\n
Software driven hardware cache management is possible. There are special ‘privileged’<\/em><\/strong><\/span> Assembler instructions to clean, invalidate, flush cache(s), and synchronize the write buffer. They can be directly executed from privileged modes. (User mode applications can control the cache through system calls only.) Most compilers support this through built-in\/intrinsic functions or inline Assembler.<\/p>\n
The Intel 64 and IA-32 architectures provide a variety of mechanisms for controlling the caching of data and instructions, and for controlling the ordering of reads\/writes between the processor, the caches, and memory.<\/p>\n
These mechanisms can be divided into two groups:<\/p>\n
\"\"\u00a0 Cache control registers and bits:<\/strong> The Intel 64 and IA-32 architectures define several dedicated registers and various bits within control registers and page\/directory-table entries that control the caching system memory locations in the L1, L2, and L3 caches. These mechanisms control the caching of virtual memory pages and of regions of physical memory.<\/p>\n
\"\"\u00a0 Cache control and memory ordering instructions:<\/strong> The Intel 64 and IA-32 architectures provide several instructions that control the caching of data, the ordering of memory reads and writes, and the prefetching of data. These instructions allow software to control the caching of specific data structures, to control memory coherency for specific locations in memory, and to force strong memory ordering at specific locations in a program.<\/p>\n
How does it work?<\/strong><\/p>\n
The Cache Control flags<\/span><\/em><\/strong> and Memory Type Range Registers (MTRRs)<\/em><\/span><\/strong> operate hierarchically for restricting caching. That is, if the CD flag<\/strong> of control register 0<\/strong> (CR0) is set, caching is prevented globally. If the CD flag<\/strong> is clear, the page-level cache control flags<\/strong> and\/or the MTRRs<\/strong> can be used to restrict caching.<\/p>\n
Tip:<\/strong> The memory type range registers (MTRRs)<\/strong> provide a mechanism for associating the memory types with physical-address ranges in system memory. They allow the processor to optimize operations for different types of memory such as RAM, ROM, frame-buffer memory, and memory-mapped I\/O devices. They also simplify system hardware design by eliminating the memory control pins used for this function on earlier IA-32 processors and the external logic needed to drive them.<\/div>\n
If there is an overlap of page-level<\/strong> and MTRR caching controls<\/strong>, the mechanism that prevents caching has precedence. For example, if an MTRR<\/strong> makes a region of system memory uncacheable<\/strong>, a page-level caching control cannot be used<\/span><\/em><\/strong> to enable caching for a page in that region. The converse is also true; that is, if a page-level caching control designates a page as uncacheable, an MTRR cannot be used to make the page cacheable.<\/p>\n
In cases where there is a overlap in the assignment of the write-back<\/strong> and write-through<\/strong> caching policies to a page and a region of memory, the write-through policy takes precedence<\/span><\/em><\/strong>. The write-combining policy -which can only be assigned through an MTRR<\/strong> or Page Attribute Table (PAT)<\/strong>– takes precedence over either write-through or write-back. The selection of memory types at the page level varies depending on whether PAT is being used to select memory types for pages.<\/p>\n
Tip:<\/strong> The Page Attribute Table (PAT)<\/strong> extends the IA-32 architecture\u2019s page-table format to allow memory types to be assigned to regions of physical memory based on linear address mappings. The PAT is a companion feature to the MTRRs; that is, the MTRRs allow mapping of memory types to regions of the physical address space, where the PAT allows mapping of memory types to pages within the linear address space. The MTRRs are useful for statically describing memory types for physical ranges, and are typically set up by the system BIOS. The PAT extends the functions of the PCD<\/strong> and PWT bits<\/strong> in page tables to allow all five of the memory types that can be assigned with the MTRRs (plus one additional memory type) to also be assigned dynamically to pages of the linear address space.<\/div>\n
 <\/p>\n
\"\"<\/p>\n
 <\/p>\n
CPU Control Registers<\/strong><\/p>\n
Generally speaking, control registers (CR0<\/strong>, CR1<\/strong>, CR2<\/strong>, CR3<\/strong>, and CR4<\/strong>) determine operating mode of the processor and the characteristics of the currently executing task. These registers are 32 bits in all 32-bit modes and compatibility mode. In 64-bit mode, control registers are expanded to 64 bits.<\/p>\n
\"\"<\/a><\/p>\n
The MOV CRn<\/strong> instructions are used to manipulate the register bits. These instructions can be executed only when the current privilege level is 0.<\/p>\n\n\n\n\n\n\n\n\n\n
Instruction<\/th>\n64-bit Mode<\/th>\nLegacy Mode<\/th>\nDescription<\/th>\n<\/tr>\n
MOV r32, CR0\u2013CR7<\/td>\n–<\/td>\nValid<\/td>\nMove control register to r32.<\/td>\n<\/tr>\n
MOV r64, CR0\u2013CR7<\/td>\nValid<\/td>\n–<\/td>\nMove extended control register to r64.<\/td>\n<\/tr>\n
MOV r64, CR8<\/td>\nValid<\/td>\n–<\/td>\nMove extended CR8 to r64.<\/td>\n<\/tr>\n
MOV CR0\u2013CR7, r32<\/td>\n–<\/td>\nValid<\/td>\nMove r32 to control register.<\/td>\n<\/tr>\n
MOV CR0\u2013CR7, r64<\/td>\nValid<\/td>\n–<\/td>\nMove r64 to extended control register.<\/td>\n<\/tr>\n
MOV CR8, r64<\/td>\nValid<\/td>\n–<\/td>\nMove r64 to extended CR8.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Tip:<\/strong> When loading control registers, programs should not attempt to change the reserved bits<\/strong>; that is, always set reserved bits to the value previously read. An attempt to change CR4’s reserved bits will cause a general protection fault. Reserved bits in CR0 and CR3 remain clear after any load of those registers; attempts to set them have no impact.<\/div>\n
The Intel 64 and IA-32 architectures provide the following cache-control registers and bits for use in enabling or restricting caching to various pages or regions in memory:<\/p>\n
\"\"<\/a><\/p>\n
\"\"\u00a0 CD flag (bit 30 of control register CR0):<\/strong> Controls caching of system memory locations. If the CD flag is clear, caching is enabled for the whole of system memory, but may be restricted for individual pages or regions of memory by other cache-control mechanisms. When the CD flag is set, caching is restricted in the processor\u2019s caches (cache hierarchy) for the P6 and more recent processor families. With the CD flag set, however, the caches will still respond to snoop traffic. Caches should be explicitly flushed to insure memory coherency. For highest processor performance, both the CD and the NW flags in control register CR0 should be cleared. To insure memory coherency after the CD flag is set, the caches should be explicitly flushed. (Setting the CD flag for the P6 and more recent processor families modify cache line fill and update behaviour. Also, setting the CD flag on these processors do not force strict ordering of memory accesses unless the MTRRs are disabled and\/or all memory is referenced as uncached.)<\/p>\n
\"\"\u00a0 NW flag (bit 29 of control register CR0):<\/strong> Controls the write policy for system memory locations. If the NW and CD flags are clear, write-back is enabled for the whole of system memory, but may be restricted for individual pages or regions of memory by other cache-control mechanisms.<\/p>\n
\"\"\u00a0 PCD and PWT flags (in paging-structure entries):<\/strong> Control the memory type used to access paging structures and pages.<\/p>\n
\"\"\u00a0 PCD and PWT flags (in control register CR3):<\/strong> Control the memory type used to access the first paging structure of the current paging-structure hierarchy.<\/p>\n
\"\"\u00a0 G (global) flag in the page-directory and page-table entries:<\/strong> Controls the flushing of TLB entries for individual pages.<\/p>\n
\"\"\u00a0 PGE (page global enable) flag in control register CR4:<\/strong> Enables the establishment of global pages with the G flag.<\/p>\n
\"\"\u00a0 Memory type range registers (MTRRs):<\/strong> Control the type of caching used in specific regions of physical memory.<\/p>\n
\"\"\u00a0 Page Attribute Table (PAT) MSR:<\/strong> Extends the memory typing capabilities of the processor to permit memory types to be assigned on a page-by-page basis.<\/p>\n
\"\"\u00a0 3rd Level Cache Disable flag (bit 6 of IA32_MISC_ENABLE MSR):<\/strong> Allows the L3 cache to be disabled and enabled, independently of the L1 and L2 caches. (Available only in processors based on Intel NetBurst microarchitecture)<\/p>\n
\"\"\u00a0 KEN# and WB\/WT# pins (Pentium processor):<\/strong> Allow external hardware to control the caching method used for specific areas of memory. They perform similar (but not identical) functions to the MTRRs in the P6 family processors.<\/p>\n
\"\"\u00a0 PCD and PWT pins (Pentium processor):<\/strong> These pins (which are associated with the PCD and PWT flags in control register CR3 and in the page-directory and page-table entries) permit caching in an external L2 cache to be controlled on a page-by-page basis, consistent with the control exercised on the L1 cache of these processors. (The P6 and more recent processor families do not provide these pins because the L2 cache is embedded in the chip package.)<\/p>\n
 <\/p>\n
\"\"<\/p>\n
 <\/p>\n
How to Manage CPU Cache using Assembly Language<\/strong><\/p>\n
The Intel 64 and IA-32 architectures provide several instructions for managing the L1, L2, and L3 caches. The INVD<\/strong> and WBINVD<\/strong> instructions are privileged instructions and operate on the L1, L2 and L3 caches as a whole. The PREFETCHh<\/strong>, CLFLUSH<\/strong> and CLFLUSHOPT<\/strong> instructions and the non-temporal move instructions (MOVNTI<\/strong>, MOVNTQ<\/strong>, MOVNTDQ<\/strong>, MOVNTPS<\/strong>, and MOVNTPD<\/strong>) offer more granular control over caching, and are available to all privileged levels.<\/p>\n
The INVD<\/strong> and WBINVD<\/strong> instructions are used to invalidate the contents of the L1, L2, and L3 caches. The INVD<\/strong> instruction invalidates all internal cache entries, then generates a special-function bus cycle that indicates that external caches also should be invalidated. The INVD<\/strong> instruction should be used with care<\/strong><\/span><\/em>. It does not force a write-back of modified cache lines; therefore, data stored in the caches and not written back to system memory will be lost. Unless there is a specific requirement or benefit to invalidating the caches without writing back the modified lines (such as, during testing or fault recovery where cache coherency with main memory is not a concern), software should use the WBINVD<\/strong> instruction.<\/p>\n
In theory, WBINVD<\/strong> instruction performs the following steps:<\/p>\n
WriteBack(InternalCaches);\r\nFlush(InternalCaches);\r\nSignalWriteBack(ExternalCaches);\r\nSignalFlush(ExternalCaches);\r\nContinue;<\/pre>\n
The WBINVD<\/strong> instruction first writes back any modified lines in all the internal caches, then invalidates the contents of both the L1, L2, and L3 caches. It ensures that cache coherency with main memory is maintained regardless of the write policy in effect (that is, write-through or write-back). Following this operation, the WBINVD<\/strong> instruction generates one (P6 family processors) or two (Pentium and Intel486 processors) special-function bus cycles to indicate to external cache controllers that write-back of modified data followed by invalidation of external caches should occur. The amount of time or cycles for WBINVD<\/strong> to complete will vary due to the size of different cache hierarchies and other factors. As a consequence, the use of the WBINVD<\/strong> instruction can have an impact on interrupt\/event response time.<\/p>\n
The PREFETCHh<\/strong> instructions allow a program to suggest to the processor that a cache line from a specified location in system memory be prefetched into the cache hierarchy.<\/p>\n
The CLFLUSH<\/strong> and CLFLUSHOPT<\/strong> instructions allow selected cache lines to be flushed from memory. These instructions give a program the ability to explicitly free up cache space, when it is known that cached section of system memory will not be accessed in the near future.<\/p>\n
The non-temporal move instructions (MOVNTI<\/strong>, MOVNTQ<\/strong>, MOVNTDQ<\/strong>, MOVNTPS<\/strong>, and MOVNTPD<\/strong>) allow data to be moved from the processor\u2019s registers directly into system memory without being also written into the L1, L2, and\/or L3 caches. These instructions can be used to prevent cache pollution when operating on data that is going to be modified only once before being stored back into system memory. These instructions operate on data in the general-purpose, MMX, and XMM registers.<\/p>\n
 <\/p>\n
\"\"<\/p>\n
 <\/p>\n
How to Disable Hardware Caching<\/strong><\/p>\n
To disable the L1, L2, and L3 caches after they have been enabled and have received cache fills, perform the following steps:<\/p>\n
1.)<\/strong> Enter the no-fill cache mode. (Set the CD flag<\/strong> in control register CR0<\/strong> to 1 and the NW<\/strong> flag to 0.<\/p>\n
2.)<\/strong> Flush all caches using the WBINVD<\/strong> instruction.<\/p>\n
3.)<\/strong> Disable the MTRRs<\/strong> and set the default memory type to uncached or set all MTRRs<\/strong> for the uncached memory type.<\/p>\n
The caches must be flushed (step 2) after the CD flag<\/strong> is set to insure system memory coherency. If the caches are not flushed, cache hits on reads will still occur<\/em><\/strong><\/span> and data will be read from valid cache lines.
\nThe intent of the three separate steps listed above address three distinct requirements:<\/p>\n
a.)<\/strong> Discontinue new data replacing existing data in the cache,<\/p>\n
b.)<\/strong> Ensure data already in the cache are evicted to memory,<\/p>\n
c.)<\/strong> Ensure subsequent memory references observe UC memory type semantics. Different processor implementation of caching control hardware may allow some variation of software implementation of these three requirements.<\/p>\n
Setting the CD flag<\/strong> in control register CR0<\/strong> modifies the processor\u2019s caching behaviour as indicated, but setting the CD flag<\/strong> alone may not be sufficient across all processor families to force the effective memory type for all physical memory to be UC nor does it force strict memory ordering, due to hardware implementation variations across different processor families. To force the UC memory type and strict memory ordering on all of physical memory, it is sufficient to either program the MTRRs<\/strong> for all physical memory to be UC memory type or disable all MTRRs<\/strong>.<\/p>\n
Tip:<\/strong> For the Pentium 4 and Intel Xeon processors, after the sequence of steps given above has been executed, the cache lines containing the code between the end of the WBINVD<\/strong> instruction and before the MTRRS<\/strong> have actually been disabled may be retained in the cache hierarchy. Here, to remove code from the cache completely, a second WBINVD<\/strong> instruction must be executed after the MTRRs<\/strong> have been disabled.<\/div>\n
 <\/p>\n
\"\"<\/p>\n
 <\/p>\n
References:<\/strong><\/p>\n
\"\"\u00a0 Richard Blum, “Professional Assembly Language”<\/em>, Wrox Publishing – (2005)<\/p>\n
\"\"\u00a0 Keith Cooper & Linda Torczon, “Engineering A Compiler”<\/em>, Morgan Kaufmann, 2nd Edition – (2011)<\/p>\n
\"\"\u00a0 Alexey Lyashko, “Mastering Assembly Programming”<\/em>, Packt Publishing Limited – (2017)<\/p>\n
\"\"\u00a0 “Intel\u00ae 64 and IA-32 Architectures Optimization Reference Manual”<\/em> – (April 2018)<\/p>\n
\"\"\u00a0 “Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual: Basic Architecture”<\/em> – (November 2018)<\/p>\n
\"\"\u00a0 “Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual: Instruction Set Reference A-Z”<\/em> – (November 2018)<\/p>\n
\"\"\u00a0 “Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual: System Programming Guide”<\/em> – (November 2018)<\/p>\n
\"\"\u00a0 “Intel\u00ae 64 and IA-32 Architectures Software Developer\u2019s Manual: Model-Specific Registers”<\/em> – (November 2018)<\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
(Cover Photo:\u00a0 \u00a9 Granger – “Lion Tamer” The American animal tamer Clyde Beatty performing in the 1930s.) The processor’s caches are for the most part transparent to software. When enabled, instructions and data flow through these caches without the need for explicit software control. However, knowledge of the behavior of these caches may be useful … Continue reading Taming a Beast: CPU Cache<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":3080,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26,17,7],"tags":[175,177,179,180,194,195,204,178,174,186,185,191,205,206,207,187,198,196,200,199,197,190,188,189,193,183,184,176,192,182,181],"class_list":["post-3073","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-articles","category-retrodemo","category-gamedev","tag-c-c","tag-cache","tag-cache-hit","tag-cache-line-fill","tag-clflush","tag-clflushopt","tag-const","tag-control-register","tag-cpu","tag-ia-32","tag-intel-64","tag-invd","tag-l1-cache","tag-l2-cache","tag-l3-cache","tag-memory-type-range-registers","tag-movntdq","tag-movnti","tag-movntpd","tag-movntps","tag-movntq","tag-mtrr","tag-page-attribute-table","tag-pat","tag-prefetchh","tag-snooping","tag-translation-lookaside-buffer","tag-volatile","tag-wbinvd","tag-write-allocation","tag-write-hit"],"_links":{"self":[{"href":"http:\/\/mertboru.com\/index.php?rest_route=\/wp\/v2\/posts\/3073","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/mertboru.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/mertboru.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/mertboru.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/mertboru.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3073"}],"version-history":[{"count":1,"href":"http:\/\/mertboru.com\/index.php?rest_route=\/wp\/v2\/posts\/3073\/revisions"}],"predecessor-version":[{"id":3703,"href":"http:\/\/mertboru.com\/index.php?rest_route=\/wp\/v2\/posts\/3073\/revisions\/3703"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/mertboru.com\/index.php?rest_route=\/wp\/v2\/media\/3080"}],"wp:attachment":[{"href":"http:\/\/mertboru.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3073"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/mertboru.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3073"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/mertboru.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3073"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}