[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