linux-kernel - Re: [PATCH] mm,cma: remove pfn_range_valid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 06 Mar 2020 17:22:08 -0500
From:   Rik van Riel <riel@...riel.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        kernel-team@...com, Anshuman Khandual <anshuman.khandual@....com>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Vlastimil Babka <vbabka@...e.cz>, Qian Cai <cai@....pw>,
        Roman Gushchin <guro@...com>
Subject: Re: [PATCH] mm,cma: remove pfn_range_valid_contig

On Fri, 2020-03-06 at 17:06 -0500, Rik van Riel wrote:
> The function pfn_range_valid_contig checks whether all memory in the
> target area is free. This causes unnecessary CMA failures, since
> alloc_contig_range will migrate movable memory out of a target range,
> and has its own sanity check early on in has_unmovable_pages, which
> is called from start_isolate_page_range & set_migrate_type_isolate.
> 
> Relying on that has_unmovable_pages call simplifies the CMA code and
> results in an increased success rate of CMA allocations.

Thinking about this some more, could we get away with
entirely removing alloc_contig_pages, and simply having
the hugetlb code use cma_alloc?

That might be simpler still.

It also seems like it could make the success rate of 
1GB hugepage allocation much more predictable, because
the kernel will place only movable memory allocations
inside the CMA area, and we would never try to allocate
a 1GB huge page from a 1GB memory area with unmovable
pages.

It would be possible for the code in hugetlb_init() to 
invoke the cma setup code as needed, to set aside an 
appropriate amount of memory for movable allocations
(and later CMA 1GB hugepages) only.

Then again, if the allocation reliability ends up
being eg. 90% instead of 100%, we may need some way
to set up the memory pool for CMA hugepage allocation
a little larger, and not size it automatically to the
desired number of hugepages (with nothing to spare).

An explicit hugepage_cma=nG option would cover that.

Thoughts?

-- 
All Rights Reversed.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)