[LITMUS^RT] prop/uncachedev: mmap() CPU-uncachable pages.

Glenn Elliott gelliott at cs.unc.edu
Fri Mar 8 07:22:54 CET 2013


Hello All,

I've pushed a branch to github named "prop/uncachedev"  I think its inclusion in mainline would be a great help in our continued work with caches.

From the commit (434eef21cb):

This patch creates a new character device, uncachedev.
Pages of RAM allocated by this device are not cached by
CPUs.

Uses for such pages:
1) Determining *very* pessimistic emperical worst-
   case execution times.
2) Compare against performance with caches (quantify
   the avg. case benefit).
3) Deterministic memory accesses (access cannot cause a
   cache eviction.)
4) Theoretically, increased performance can be achieved
   by storing infrequently accessed data in uncache pages.

uncachedev allocates pages with the pgprot_noncached() page
attribute for user applications. Since pages allocated by
uncachedev are not locked in memory by default, applications
with any access level may mmap pages with uncachedev.

Limitations:
1) Uncache pages must be MAP_PRIVATE.
2) Remapping not supported.

Usage (user level):
	int size = NR_PAGES*PAGE_SIZE;
	int fd = open("/dev/litmus/uncache", O_RDWR);
	char *data = mmap(NULL, size, PROT_READ | PROT_WRITE,
					MAP_PRIVATE, fd, 0); /* must be MAP_PRIVATE */
	<...do stuff...>
	munmap(data, size);

I'll also be pushing a companion patch to liblitmus that adds a test tool for uncachedev.  It can be used test uncachedev as well as profile the cost of uncacheable memory.  With unoptimized code on Bonham (Intel Xeon X5650), execution times with uncached memory were 30x greater than normal memory.  However, when my test code was compiled with -O2, this gap grew to be over 100x!  This huge difference is due to the very small working set size of my test application (just the first byte of a uncache page).  I verified that the system behaved properly by profiling with tools/perf-stat.  perf reports the expected number of cache misses for uncache data.

Here's a sample of perf's output (I forced all computation and memory to reside on a single NUMA node).

Uncached memory.  Nearly 100% cache misses.
> root at bonham:/home/gelliott/LitmusGPU/liblitmus# numactl -m 0 -N 0 perf stat -B -e cache-misses:u,cache-references:u ./uncache -u
> Page Size: 4096
> Running data access test.
> Allocating 16 uncacheable pages.
> Data allocated at 0x7f8d83197000.
> Beginning tests...
> Uncache Time: 1617009us
> 
>  Performance counter stats for './uncache -u':
> 
>         10,000,182 cache-misses:u            #   99.971 % of all cache refs    
>         10,003,093 cache-references:u                                          
> 
>        1.623216983 seconds time elapsed

Same code, with regular cacheable memory.  I believe that the total number of cache references is low because application data is "cached" in registers, or perf doesn't profile the L1.
> root at bonham:/home/gelliott/LitmusGPU/liblitmus# numactl -m 0 -N 0 perf stat -B -e cache-misses:u,cache-references:u ./uncache -c
> Page Size: 4096
> Running data access test.
> Allocating 16 cacheable pages.
> Data allocated at 0x7f8e38ac3000.
> Beginning tests...
> Cache Time: 15040us
> 
>  Performance counter stats for './uncache -c':
> 
>                 14 cache-misses:u            #    0.445 % of all cache refs    
>              3,148 cache-references:u                                          
> 
>        0.016859298 seconds time elapsed



And the output comparing runtimes (optimized):
> Page Size: 4096
> Timing cached pages...
> Running data access test.
> Allocating 16 cacheable pages.
> Data allocated at 0x7f53c292e000.
> Beginning tests...
> Cache Time: 15030us
> Timing uncached pages...
> Running data access test.
> Allocating 16 uncacheable pages.
> Data allocated at 0x7f53c292e000.
> Beginning tests...
> Uncache Time: 1616430us
> Uncached/Cached Ratio: 107.546906


Thanks to Chris for helping me with early issues on this!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20130308/c0a562fe/attachment.html>


More information about the litmus-dev mailing list