From: Rik van Riel <riel@surriel.com>
To: Michal Hocko <mhocko@kernel.org>, Roman Gushchin <guro@fb.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
linux-mm@kvack.org, kernel-team@fb.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm: hugetlb: optionally allocate gigantic hugepages using cma
Date: Tue, 10 Mar 2020 15:46:51 -0400 [thread overview]
Message-ID: <43e2e8443288260aa305f39ba566f81bf065d010.camel@surriel.com> (raw)
In-Reply-To: <20200310193622.GC8447@dhcp22.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 982 bytes --]
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.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-03-10 19:47 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-10 0:25 [PATCH v2] mm: hugetlb: optionally allocate gigantic hugepages using cma Roman Gushchin
2020-03-10 0:30 ` Roman Gushchin
2020-03-10 8:45 ` Michal Hocko
2020-03-10 17:25 ` Roman Gushchin
2020-03-10 17:37 ` Michal Hocko
2020-03-16 1:08 ` Rik van Riel
2020-03-10 17:38 ` Mike Kravetz
2020-03-10 17:42 ` Michal Hocko
2020-03-10 9:01 ` Michal Hocko
2020-03-10 17:30 ` Roman Gushchin
2020-03-10 17:39 ` Michal Hocko
2020-03-10 17:58 ` Roman Gushchin
2020-03-10 17:27 ` Mike Kravetz
2020-03-10 18:05 ` Roman Gushchin
2020-03-10 18:22 ` Rik van Riel
2020-03-10 18:33 ` Mike Kravetz
2020-03-10 18:54 ` Andreas Schaufler
2020-03-10 18:56 ` Roman Gushchin
2020-03-10 19:00 ` Andreas Schaufler
2020-03-10 19:19 ` Roman Gushchin
2020-03-10 19:36 ` Michal Hocko
2020-03-10 19:46 ` Rik van Riel [this message]
2020-03-10 20:11 ` Mike Kravetz
2020-03-10 20:15 ` Rik van Riel
2020-03-10 20:29 ` Mike Kravetz
2020-03-10 20:38 ` Rik van Riel
2020-03-10 20:29 ` Roman Gushchin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43e2e8443288260aa305f39ba566f81bf065d010.camel@surriel.com \
--to=riel@surriel.com \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mike.kravetz@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).