On 05/22/2018 06:41 PM, Reinette Chatre wrote: > On 5/21/2018 4:48 PM, Mike Kravetz wrote: >> I'm guessing that most (?all?) allocations will be order based. The use >> cases I am aware of (hugetlbfs, Intel Cache Pseudo-Locking, RDMA) are all >> order based. However, as commented in previous version taking arbitrary >> nr_pages makes interface more future proof. >> > > I noticed this Cache Pseudo-Locking statement and would like to clarify. > I have not been following this thread in detail so I would like to > apologize first if my comments are out of context. > > 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? Vlastimil -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
