Usage Instructions

[seceng-jan]

Hi,

thank you for the interesting paper and uploading your code. I have some troubles understanding the output of the programs unfortunately. test-evict does not appear to output anything and the test-evict-combine and -ratio do not seem to terminate but at least print some numbers. What do these numbers mean and (how) can I use your code to benchmark eviction set creation on my CPU? I tired an i7-7600U and an i5-8265U.

The output for test-evict-ratio looks like this:

sudo ./test-evict-ratio 
Failed to allocate pool using huge pages. Use normal pages instead.
1000    0.460000
1100    0.550000
1210    0.655000
1331    0.660000
1464    0.610000
1610    0.585000
1771    0.630000
1948    0.540000
2142    0.585000
2356    0.530000
2591    0.520000
2850    0.505000
3135    0.595000
3448    0.445000
3792    0.590000
4171    0.535000
4588    0.545000
5046    0.545000
5550    0.515000
6105    0.510000
6715    0.530000
7386    0.575000
8124    0.610000
8936    0.650000
9829    0.720000
10811   0.700000
11892   0.675000

... and test-evict-combine like this:

./test-evict-combine
Failed to allocate pool using huge pages. Use normal pages instead.
find candidate set
failed with iteration 501 > 500! ltsz = 3028
1find candidate set
failed with iteration 501 > 500! ltsz = 2843
finished with maximal rollback! ltsz = 2346
find candidate set
failed with iteration 502 > 500! ltsz = 8334
finished with maximal rollback! ltsz = 12102

Thank you for helping out!

[wsong83]

First of all, thanks for trying the project.

One of main suggestions is: The code does not run out of the box. Sorry to say that the parameters, which probably need tuning for different computers, are not exposed to the run-time command line but a C++ file (

smart-cache-evict/common/definitions.cpp

Line 28 in 89f7413

CFG_SET_ENTRY("candidate_size", CFG.candidate_size, 0 )

). You will need to tune these parameters and recompile for a good result, if the algorithm does work on your computer. Please see our RAID 2019 paper for methods of how to tweak these parameters.

Regarding the result of test-evict-ratio, for each line, the first number is the size of candidate set being created, and the second number is the estimated probabilty that this candidate set can be used to evict a randomly select victim address. Basically, this is a test to get the proper size of the candidate set on your computer.

There is no need to run any command in sudo. To enable huge page, you need to change the default value of vm.nr_hugepages (0 by default) using sysctl. You do need sudo for this one. Once this OS parameter is changed (meaning OS allow a certain number of huge pages to be allocated), the test will allocate huge pages.

As for test-evict-combine, the result is trying to say, the algorithm fails on your computer with the current parameters. For example:

failed with iteration 501 > 500! ltsz = 2843

One trial fails after a total of 501 iterations without any progress. During the process, the candidate set has been prune to 2843 elements, which is quite far away from the LLC.way (which normally 11 to 16 depending on your computer).

finished with maximal rollback! ltsz = 12102

Seems rollback is enabled in this case and the test fails with the maximal number of rollback reached. The final size of the pruned candidate set is 12102, still quite large.

By showing the final size of the prune candidate set, it give you a sense whether the parameter is better or worse. Normally when the test begin to converge to candidate sets < 100 elements, the algorithm begins to work.

One hint for you, do check this one:

smart-cache-evict/common/definitions.cpp

Line 46 in 89f7413

CFG_SET_ENTRY("elem_size", CFG.elem_size, SZ_CL )

Currently the elem_size is set to SZ_CL, which mean every element in the candidate set a totally random cache line. This is not necessary on current computers, because the VA[11:6] == PA[11:6]. To use this and significantly reduce the initial size of candidate sets, set it to SZ_PG (page size).

FInal remark, we have tested the algorithm on i7-3770, i7-8700 and Xeon-4110 (in RAID-2019 paper). Using totally random cache lines (SZ_CL) does not work on i7-8700. Thus I assume it hardly work on i7-7600U. We suspect the reason is too much noise when using a super large candidate set. SZ_PG with proper parameters should work just fine.

We do not reverse-eng the page mapping to verify the collected eviction set but rely on extra tests at the end of the test.

[seceng-jan]

Thank you very much for the comprehensive response, it saved me a lot of time! It works nicely now.