From: Oscar Salvador <osalvador@suse.de>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: David Hildenbrand <david@redhat.com>,
Muchun Song <songmuchun@bytedance.com>,
Michal Hocko <mhocko@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Oscar Salvador <osalvador@suse.de>
Subject: [RFC PATCH 0/2] Make alloc_contig_range handle Hugetlb pages
Date: Mon, 8 Feb 2021 11:38:10 +0100 [thread overview]
Message-ID: <20210208103812.32056-1-osalvador@suse.de> (raw)
Hi,
I promised to Mike to have a look into this a few weeks ago.
This is my first attempt.
I carried out some tests with a module that tries to allocate with
alloc_contig_range() from a range where we have free and in-use hugetlb
pages.
So far I did not spot any problem and it worked.
Please, note that it is not fully completed, as some things remain to be sorted
out (see list below), but I wanted to publish it to see whether the way I am
going makes sense to people, or I am doing something worrisome.
E.g:
- What happens when we allocated a new hugetlb page, but we cannot dissolve
the old one? (should not really happen (tm))
- When allocating the new hugetlb page I try to do it in the same node
the old one is. Should we be more flexible and allow to fallback to
other nodes?
Userspace can request hugetlb on specific nodes [1], but it can also
request them through generic interfaces [2].
- Problems I did not foresee yet
[1] /sys/devices/system/node/nodeX/hugepages/*
[2] /proc/sys/vm/nr_hugepages or /sys/kernel/mm/hugepages/*
Oscar Salvador (2):
mm,page_alloc: Make alloc_contig_range handle in-use hugetlb pages
mm,page_alloc: Make alloc_contig_range handle free hugetlb pages
include/linux/hugetlb.h | 6 ++++++
mm/compaction.c | 28 ++++++++++++++++++++++++++++
mm/hugetlb.c | 35 +++++++++++++++++++++++++++++++++++
mm/vmscan.c | 5 +++--
4 files changed, 72 insertions(+), 2 deletions(-)
--
2.16.3
next reply other threads:[~2021-02-08 10:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-08 10:38 Oscar Salvador [this message]
2021-02-08 10:38 ` [RFC PATCH 1/2] mm,page_alloc: Make alloc_contig_range handle in-use hugetlb pages Oscar Salvador
2021-02-10 8:56 ` David Hildenbrand
2021-02-10 14:09 ` Oscar Salvador
2021-02-10 14:11 ` David Hildenbrand
2021-02-10 14:14 ` Oscar Salvador
2021-02-10 14:22 ` David Hildenbrand
2021-02-11 0:56 ` Mike Kravetz
2021-02-11 10:40 ` David Hildenbrand
2021-02-08 10:38 ` [RFC PATCH 2/2] mm,page_alloc: Make alloc_contig_range handle free " Oscar Salvador
2021-02-10 8:23 ` David Hildenbrand
2021-02-10 14:24 ` Oscar Salvador
2021-02-10 14:36 ` David Hildenbrand
2021-02-25 21:43 ` Mike Kravetz
2021-02-25 22:15 ` David Hildenbrand
2021-02-11 1:16 ` Mike Kravetz
2021-02-11 21:38 ` Oscar Salvador
2021-02-08 10:39 ` [RFC PATCH 0/2] Make alloc_contig_range handle Hugetlb pages Oscar Salvador
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=20210208103812.32056-1-osalvador@suse.de \
--to=osalvador@suse.de \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mike.kravetz@oracle.com \
--cc=songmuchun@bytedance.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.