From: Peter Xu <peterx@redhat.com>
To: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: Breno Leitao <leitao@debian.org>, Rik van Riel <riel@surriel.com>,
Muchun Song <muchun.song@linux.dev>,
Naoya Horiguchi <nao.horiguchi@gmail.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Ackerley Tng <ackerleytng@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
peterx@redhat.com, Oscar Salvador <osalvador@suse.de>
Subject: [PATCH v2 0/7] mm/hugetlb: Refactor hugetlb allocation resv accounting
Date: Tue, 7 Jan 2025 15:39:55 -0500 [thread overview]
Message-ID: <20250107204002.2683356-1-peterx@redhat.com> (raw)
[based on akpm/mm-unstable, latest ca95745c20ad, of Jan 7th 2025]
v2:
- Rebase to latest mm-unstable
- Added R-b and T-b for Ackerley on patch 1
(Ackerley: I was conservative on the tags here to only attach them in
patch 1, even though it seems you mentioned you agree/tested with the
whole series. Please feel free to provide your tag again on the cover
letter if you want, thanks)
This is a follow up on Ackerley's series here as replacement:
https://lore.kernel.org/r/cover.1728684491.git.ackerleytng@google.com
The goal of this series is to cleanup hugetlb resv accounting, especially
during folio allocation, to decouple a few things:
- Hugetlb folios v.s. Hugetlbfs: IOW, the hope is in the future hugetlb
folios can be allocated completely without hugetlbfs.
- Decouple VMA v.s. hugetlb folio allocations: allocating a hugetlb folio
should not always require a hugetlbfs VMA. For example, either it got
allocated from the inode level (see hugetlbfs_fallocate() where it used
a pesudo VMA for allocation), or it can be allocated by other kernel
subsystems.
It paves way for other users to allocate hugetlb folios out of either
system reservations, or subpools (instead of hugetlbfs, as a file system).
For longer term, this prepares hugetlb as a separate concept versus
hugetlbfs, so that hugetlb folios can be allocated by not only hugetlbfs
and other things.
Tests I've done:
- I had a reproducer in patch 1 for the bug I found, this will start to
work after patch 1 or the whole set applied.
- Hugetlb regression tests (on x86_64 2MBs), includes:
- All vmtests on hugetlbfs
- libhugetlbfs test suite (which may fail some tests, but no new failures
will be introduced by this series, so all such failures happen before
this series so shouldn't be relevant).
Comments welcomed, thanks.
Peter Xu (7):
mm/hugetlb: Fix avoid_reserve to allow taking folio from subpool
mm/hugetlb: Stop using avoid_reserve flag in fork()
mm/hugetlb: Rename avoid_reserve to cow_from_owner
mm/hugetlb: Clean up map/global resv accounting when allocate
mm/hugetlb: Simplify vma_has_reserves()
mm/hugetlb: Drop vma_has_reserves()
mm/hugetlb: Unify restore reserve accounting for new allocations
fs/hugetlbfs/inode.c | 2 +-
include/linux/hugetlb.h | 4 +-
mm/hugetlb.c | 237 ++++++++++++++++++----------------------
3 files changed, 107 insertions(+), 136 deletions(-)
--
2.47.0
next reply other threads:[~2025-01-07 20:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-07 20:39 Peter Xu [this message]
2025-01-07 20:39 ` [PATCH v2 1/7] mm/hugetlb: Fix avoid_reserve to allow taking folio from subpool Peter Xu
2025-01-13 11:02 ` Oscar Salvador
2025-01-07 20:39 ` [PATCH v2 2/7] mm/hugetlb: Stop using avoid_reserve flag in fork() Peter Xu
2025-01-13 11:05 ` Oscar Salvador
2025-01-07 20:39 ` [PATCH v2 3/7] mm/hugetlb: Rename avoid_reserve to cow_from_owner Peter Xu
2025-01-13 11:20 ` Oscar Salvador
2025-01-13 16:19 ` Peter Xu
2025-01-16 10:15 ` Oscar Salvador
2025-01-16 14:26 ` Peter Xu
2025-01-07 20:39 ` [PATCH v2 4/7] mm/hugetlb: Clean up map/global resv accounting when allocate Peter Xu
2025-01-13 22:57 ` Ackerley Tng
2025-01-14 18:25 ` Peter Xu
2025-01-07 20:40 ` [PATCH v2 5/7] mm/hugetlb: Simplify vma_has_reserves() Peter Xu
2025-01-07 20:40 ` [PATCH v2 6/7] mm/hugetlb: Drop vma_has_reserves() Peter Xu
2025-01-07 20:40 ` [PATCH v2 7/7] mm/hugetlb: Unify restore reserve accounting for new allocations Peter Xu
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=20250107204002.2683356-1-peterx@redhat.com \
--to=peterx@redhat.com \
--cc=ackerleytng@google.com \
--cc=akpm@linux-foundation.org \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=nao.horiguchi@gmail.com \
--cc=osalvador@suse.de \
--cc=riel@surriel.com \
--cc=roman.gushchin@linux.dev \
/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