大的物理连续存储区

Question

For my M.Sc. thesis, I have to reverse-engineer the hash function Intel uses inside its CPUs to spread data among Last Level Cache slices in Sandy Bridge and newer generations. To this aim, I am developing an application in Linux, which needs a physically contiguous memory area in order to make my tests. The idea is to read data from this area, so that they are cached, probe if older data have been evicted (through delay measures or LLC miss counters) in order to find colliding memory addresses and finally discover the hash function by comparing these colliding addresses. The same procedure has already been used in Windows by a researcher, and proved to work.

To do this, I need to allocate an area that must be large (64 MB or more) and fully cachable, so without DMA-friendly options in TLB. How can I perform this allocation?

To have a full control over the allocation (ie, for it to be really physically contiguous), my idea was to write a Linux module, export a device and mmap() it from userspace, but I do not know how to allocate so much contiguous memory inside the kernel. I heard about Linux Contiguous Memory Allocator (CMA), but I don't know how it works

Answer 1

Applications don't see physical memory, a process have some address space in virtual memory . Read about the MMU (what is contiguous in virtual space might not really be physically contiguous and vice versa)

You might perhaps want to lock some memory using mlock(2)

But your application will be scheduled, and other processes (or scheduled tasks) would dirty your CPU cache . See also sched_setaffinity(2)

^{(and even kernel code might be perhaps preempted)}

Answer 2

This page on Kernel Newbies , has some ideas about memory allocation. But the max for get_free_pages looks like 8MiB. (Perhaps that's a compile-time constraint?)

Since this would be all-custom, you could explore the mem= boot parameter of the linux kernel. This will limit the amount of memory used, and you can party all over the remaining memory without anyone knowing. Heck, if you boot up a busybox system, you could probably do mem=32M , but even mem=256M should work if you're not booting a GUI.

You will also want to look into the Offline Scheduler (and here ). It "unplugs" the CPU from Linux so you can have full control over ALL code running on it. (Some parts of this are already in the mainline kernel, and maybe all of it is.)