Programmatically Disable Hardware Prefetching on Amd Systems

programmatically disable hardware prefetching on AMD systems

All AMD Family 10h processors (including Barcelona and Istanbul) have two different hardware prefetchers.

  1. The first is the traditional data cache prefetcher that recognizes contiguous streams of either ascending or descending cache line accesses. It can be disabled by setting bit 13 of MSRC001_1022 to "1".

  2. The other hardware prefetcher is the "memory controller prefetcher". This is a somewhat more general prefetcher, but only operates within the memory controller (i.e., it does not send the prefetched data to a core -- it just enables the memory controller to return it more quickly when the core requests it).

    • The primary control for this prefetcher is in PCI configuration space, Function 2, offset 11Ch, with additional control in Function 2, offset 1B0h for the processors after Barcelona.
    • I have had success in disabling and re-enabling this prefetcher on a "live" Barcelona system by updating the values in PCI configuration space via the /dev/mem device driver. (Don't try this at home!)
    • The activity of the memory controller prefetcher is shown by the hardware performance counter event 1F0h, with UnitMasks 02 and 04.
    • Note that the memory controller prefetcher for Shanghai/Istanbul/MagnyCours operates "coherently" (meaning that cache coherence probe operations are issued along with the memory prefetches), while the memory controller prefetcher in Barcelona does not issue cache coherence operations (they don't get issued until the core's request for the cache line arrives at the memory controller).

The stuff above is documented in the BIOS and Kernel Developer's Guide for Family 10h processors: http://support.amd.com/us/Processor_TechDocs/31116.pdf

How do I programmatically disable hardware prefetching?

From the Intel reference:

This instruction must be executed at privilege level 0 or in real-address mode; otherwise, a general protection exception #GP(0) will be generated. Specifying a reserved or unimplemented MSR address in ECX will also cause a general protection exception.

...

The CPUID instruction should be used to determine whether MSRs are supported (EDX[5]=1)
before using this instruction.

So, your fault might be related to a cpu that doesn't support MSRs or using the wrong MSR address.

There are lots of examples of using the MSRs in the kernel source:

In the kernel source, for a single cpu, it demonstrates disabling prefetch for the Xeon in arch/i386/kernel/cpu/intel.c, in the function:

static void __cpuinit Intel_errata_workarounds(struct cpuinfo_x86 *c)

The rdmsr function arguments are the msr number, a pointer to the low 32 bit word, and a pointer to the high 32 bit word.

The wrmsr function arguments are the msr number, the low 32 bit word value, and the high 32 bit word value.

multi-core or smp systems have to pass the cpu struct in as the first argument:

void rdmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 *l, u32 *h);

void wrmsr_on_cpu(unsigned int cpu, u32 msr_no, u32 l, u32 h);

Correctly disable Hardware Prefetching with MSR in Skylake

I found that this commands are working correctly. sudo modprobe msr - should be executed first though. The main problem was the way I was testing it with papi events



Related Topics



Leave a reply



Submit