Messages in this thread | | | Date | Tue, 13 Feb 2018 11:27:16 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [RFC PATCH 00/20] Intel(R) Resource Director Technology Cache Pseudo-Locking enabling |
| |
On Mon, 12 Feb 2018, Reinette Chatre wrote: > On 1/16/2018 3:38 AM, Thomas Gleixner wrote: > All tests involve a user space application that allocates (malloc() with > mlockall()) or in the case of Cache Pseudo-Locking maps using mmap()) a > 256KB region of memory. The application then randomly accesses this > region, 32 bytes at a time, measuring the latency in cycles of each > access using the rdtsc instruction. Each time a test is run it is > repeated ten times. > In both the PALLOC and CAT tests there was improvement (CAT most > significant) in latency accessing a 256KB memory region but in both > (PALLOC and CAT) 512KB of cache was set aside for application to obtain > these results. Using Cache Pseudo-Locking to access the 256KB memory > region only 256KB of cache was set aside while also reducing the access > latency when compared to both PALLOC and CAT. > > I do hope these results establishes the value of Cache Pseudo-Locking to > you.
Very nice. Thank you so much for doing this. That kind of data is really valuable.
My take away from this: All of the mechanisms are only delivering best effort and the real benefit is the reduction of average latency. The worst case outliers are in the same ballpark at seems.
> The rebased patch series used in this testing will be sent out > this week.
I'll make sure to have cycles available for review.
Thanks,
tglx
| |