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]

Message-ID: <833c188c0c1b9b0b842973952907bdabed774122.camel@surriel.com>
Date:   Tue, 10 Mar 2020 14:22:17 -0400
From:   Rik van Riel <riel@...riel.com>
To:     Roman Gushchin <guro@...com>,
        Mike Kravetz <mike.kravetz@...cle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Michal Hocko <mhocko@...nel.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, 2020-03-10 at 11:05 -0700, Roman Gushchin wrote:
> On Tue, Mar 10, 2020 at 10:27:01AM -0700, Mike Kravetz wrote:
> > 
> > > +	for_each_node_state(nid, N_ONLINE) {
> > > +		unsigned long min_pfn = 0, max_pfn = 0;
> > > +
> > > +		for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn,
> > > NULL) {
> > > +			if (!min_pfn)
> > > +				min_pfn = start_pfn;
> > > +			max_pfn = end_pfn;
> > > +		}
> > > +
> > > +		res = cma_declare_contiguous(PFN_PHYS(min_pfn), size,
> > > +					     PFN_PHYS(max_pfn), (1UL <<
> > > 30),
> > 
> > The alignment is hard coded for x86 gigantic page size.  If this
> > supports
> > more architectures or becomes arch independent we will need to
> > determine
> > what this alignment should be.  Perhaps an arch specific call back
> > to get
> > the alignment for gigantic pages.  That will require a little
> > thought as
> > some arch's support multiple gigantic page sizes.
> 
> Good point!
> Should we take the biggest possible size as a reference?
> Or the smallest (larger than MAX_ORDER)?

I would say biggest.

You can always allocate multiple smaller gigantic pages
inside the space reserved for one ginormous one.

-- 
All Rights Reversed.

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