[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <43e2e8443288260aa305f39ba566f81bf065d010.camel@surriel.com>
Date: Tue, 10 Mar 2020 15:46:51 -0400
From: Rik van Riel <riel@...riel.com>
To: Michal Hocko <mhocko@...nel.org>, Roman Gushchin <guro@...com>
Cc: Mike Kravetz <mike.kravetz@...cle.com>,
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, 2020-03-10 at 20:36 +0100, Michal Hocko wrote:
> On Tue 10-03-20 12:19:06, Roman Gushchin wrote:
> [...]
> > > I found this out by testing code and specifying
> > > hugetlb_cma=2M. Messages
> > > in log were:
> > > kernel: hugetlb_cma: reserve 2097152, 1048576 per node
> > > kernel: hugetlb_cma: successfully reserved 1048576 on node 0
> > > kernel: hugetlb_cma: successfully reserved 1048576 on node 1
> > > But, it really reserved 1GB per node.
> >
> > Good point! In the passed size is too small to cover a single huge
> > page,
> > we should probably print a warning and bail out.
>
> Or maybe you just want to make the interface the unit size rather
> than
> overall size oriented. E.g. I want 10G pages per each numa node.
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?
--
All Rights Reversed.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists