Thread (19 messages) 19 messages, 3 authors, 2018-05-28

Re: [PATCH v2 3/4] mm: add find_alloc_contig_pages() interface

From: Vlastimil Babka <hidden>
Date: 2018-05-23 11:18:14
Also in: linux-mm, lkml

On 05/22/2018 06:41 PM, Reinette Chatre wrote:
On 5/21/2018 4:48 PM, Mike Kravetz wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help