Friends I want to study the effect of cache pollution due to operating system on an application’s performance.
For this I have written a small custom benchmark program.
1. malloc an array of size = l1 data cache-size
2. repeat ... sweep this array from start to end (hit-rate = 1.0)
3. *** perform a system call that thrashes l1 data cache ***
4. sweep the array once again (expected hit-rate = ~0.7 ---> 1.0)
The step 2 of the algorithm repeatedly reads the complete array. Hopefully the array would stay in the cache and hence result in a hit-rate of 1.
After I perform the system call, I try to read the cache once again. But I assume that the OS has evicted some cache lines belonging to the user.
As you can see, the program relies on the system call to evict many user data lines from the l1 data cache. How can I achieve this ??
I assume that the system call should be either file related or stream related.
The effects on the L1 cache will vary from system call to system call. One method would be to loop through several different system calls and measure the impact of each (including, e.g. I/O-related calls like
write(), where you can vary the size of a buffer, and thus the likely impact on the cache).You will probably want to avoid system calls implemented as vsyscalls (e.g.
gettimeofday()), as they don’t require a switch into kernel-space. See [1, 2].It sounds like you want to isolate the effects on the L1d, so another thing you might want to be careful about: in your step 2, after you’ve looped through your array, the L1i cache will have been populated. After your system call completes, it’s likely that both the L1d and the L1i have been polluted, so you might also see the performance effects of i-cache misses.
To get better fine-grained measurements, you might be able to utilize hardware performance counters, depending on your architecture.