On 05/23/2018 08:07 PM, Reinette Chatre wrote: > On 5/23/2018 4:18 AM, Vlastimil Babka wrote: >> On 05/22/2018 06:41 PM, Reinette Chatre wrote: >>> Currently the Cache Pseudo-Locking allocations are order based because I >>> assumed it was required by the allocator. The contiguous regions needed >>> by Cache Pseudo-Locking will not always be order based - instead it is >>> based on the granularity of the cache allocation. One example is a >>> platform with 55MB L3 cache that can be divided into 20 equal portions. >>> To support Cache Pseudo-Locking on this platform we need to be able to >>> allocate contiguous regions at increments of 2816KB (the size of each >>> portion). In support of this example platform regions needed would thus >>> be 2816KB, 5632KB, 8448KB, etc. >> >> Will there be any alignment requirements for these allocations e.g. for >> minimizing conflict misses? > > Two views on the usage of the allocated memory are: On the user space > side, the kernel memory is mapped to userspace (using remap_pfn_range()) > and thus need to be page aligned. On the kernel side the memory is > loaded into the cache and it is here where the requirement originates > for it to be contiguous. The memory being contiguous reduces the > likelihood of physical addresses from the allocated memory mapping to > the same cache line and thus cause cache evictions of memory we are > trying to load into the cache. Hi, yeah that's what I've been thinking, and I guess page alignment is enough for that after all. I'm just not used to cache sizes and ways that are not power of two :) > I hope I answered your question, if not, please let me know which parts > I missed and I will try again. Thanks! Vlastimil > Reinette >
