linux-kernel - Re: [PATCH v2] mm: hugetlb: optionally allocate gigantic hugepages using cma

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:   Tue, 10 Mar 2020 13:29:44 -0700
From:   Roman Gushchin <guro@...com>
To:     Rik van Riel <riel@...riel.com>
CC:     Mike Kravetz <mike.kravetz@...cle.com>,
        Michal Hocko <mhocko@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Johannes Weiner <hannes@...xchg.org>, <linux-mm@...ck.org>,
        <kernel-team@...com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] mm: hugetlb: optionally allocate gigantic hugepages
 using cma

On Tue, Mar 10, 2020 at 04:15:18PM -0400, Rik van Riel wrote:
> On Tue, 2020-03-10 at 13:11 -0700, Mike Kravetz wrote:
> > On 3/10/20 12:46 PM, Rik van Riel wrote:
> > > 
> > > How would that work for architectures that have multiple
> > > possible hugetlbfs gigantic page sizes, where the admin
> > > can allocate different numbers of differently sized pages
> > > after bootup?
> > 
> > For hugetlb page reservations at boot today, pairs specifying size
> > and
> > quantity are put on the command line.  For example,
> > hugepagesz=2M hugepages=512 hugepagesz=1G hugepages=64
> > 
> > We could do something similiar for CMA.
> > hugepagesz=512M hugepages_cma=256 hugepagesz=1G hugepages_cma=64
> > 
> > That would make things much more complicated (implies separate CMA
> > reservations per size) and may be overkill for the first
> > implementation.
> > 
> > Perhaps we limit CMA reservations to one gigantic huge page
> > size.  The
> > architectures would need to define the default and there could be a
> > command line option to override.  Something like,
> > default_cmapagesz=  analogous to today's default_hugepagesz=.  Then
> > hugepages_cma= is only associated with that default gigantic huge
> > page
> > size.
> > 
> > The more I think about it, the more I like limiting CMA reservations
> > to
> > only one gigantic huge page size (per arch).
> 
> Why, though?
> 
> The cma_alloc function can return allocations of different
> sizes at the same time.
> 
> There is no limitation in the underlying code that would stop
> a user from allocating hugepages of different sizes through
> sysfs.
> 
> Allowing the system administrator to allocate a little extra
> memory for the CMA pool could also allow us to work around
> initial issues of compaction/migration failing to move some
> of the pages, while we play whack-a-mole with the last corner
> cases.

I agree. Because the cma area can be effectively used by userspace
applications even without allocating gigantic pages, there is no
need to be very greedy on setting the cma size (unlike allocating
1 GB pages on boot, where every unused page is a wasted 1 GB).