[LSF/MM TOPIC] few MM topics
Michal Hocko
mhocko at kernel.org
Thu Jan 25 02:02:19 PST 2018
On Wed 24-01-18 10:23:20, Mike Kravetz wrote:
> On 01/24/2018 01:26 AM, Michal Hocko wrote:
[...]
> > - It seems there is some demand for large (> MAX_ORDER) allocations.
> > We have that alloc_contig_range which was originally used for CMA and
> > later (ab)used for Giga hugetlb pages. The API is less than optimal
> > and we should probably think about how to make it more generic.
>
> This is also of interest to me. I actually started some efforts in this
> area. The idea (as you mention above) would be to provide a more usable
> API for allocation of contiguous pages/ranges. And, gigantic huge pages
> would be the first consumer.
>
> alloc_contig_range currently has some issues with being used in a 'more
> generic' way. A comment describing the routine says "it's the caller's
> responsibility to guarantee that we are the only thread that changes
> migrate type of pageblocks the pages fall in.". This is true, and I think
> it also applies to users of the underlying routines such as
> start_isolate_page_range. The CMA code has a mechanism that prevents two
> threads from operating on the same range concurrently. The other users
> (gigantic page allocation and memory offline) happen infrequently enough
> that we are unlikely to have a conflict. But, opening this up to more
> generic use will require at least a more generic synchronization mechanism.
Yes, that is exactly my concern and the current state of art that has to
change. I am not yet sure how. So any discussion seems interesting.
--
Michal Hocko
SUSE Labs
More information about the Linux-nvme
mailing list