From: Peter Xu <peterx@redhat.com>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: Rik van Riel <riel@surriel.com>, Breno Leitao <leitao@debian.org>,
Andrew Morton <akpm@linux-foundation.org>,
peterx@redhat.com, Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
Roman Gushchin <roman.gushchin@linux.dev>,
Naoya Horiguchi <nao.horiguchi@gmail.com>,
Ackerley Tng <ackerleytng@google.com>
Subject: [PATCH 0/7] mm/hugetlb: Refactor hugetlb allocation resv accounting
Date: Sun, 1 Dec 2024 16:22:33 -0500 [thread overview]
Message-ID: <20241201212240.533824-1-peterx@redhat.com> (raw)
[based on akpm/mm-unstable, latest 8351c1503010, of Dec 1st 2024]
This is a follow up on Ackerley's series here as replacement:
https://lore.kernel.org/r/cover.1728684491.git.ackerleytng@google.com
Ackerley, I wanted to reuse some of your patches, but when looking at this
issue I found a bug which is described in patch 1. I'll need to have that
patch to be the 1st patch of the series, and then I also found this is so
far the best way to layout this whole set. It should have gone a bit
further than what you tried to do in your series, but I assume many of your
gmem 1G patches after that will still apply on top.
The goal of this series is to cleanup hugetlb resv accounting, especially
during folio allocation. It paves way for other users to allocate hugetlb
folios out of either system reservations, or subpools (instead of
hugetlbfs, as a file system). So for the longer term, maybe there's chance
to use hugetlb to be separate concept v.s. hugetlbfs, which I hope would
work.
Going back to this small (not so much..) refactoring series. It touches
the (probably.. hard to read for most) hugetlb resv code, try to make it
more readable, decouple things so that it might be easier in the future to
allocate the folios without hugetlb VMAs.
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
Note that I found libhugetlbfs test suites can fail on some of the tests,
but it doesn't look like to be caused by this series, as I can get the same
results when I run the test suites on either akpm/mm-stable or v6.12 tag.
I didn't yet have time to look into all the issues, but the current guess
is those issues are separate from this series.
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 | 243 ++++++++++++++++++----------------------
3 files changed, 110 insertions(+), 139 deletions(-)
--
2.47.0
next reply other threads:[~2024-12-01 21:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-01 21:22 Peter Xu [this message]
2024-12-01 21:22 ` [PATCH 1/7] mm/hugetlb: Fix avoid_reserve to allow taking folio from subpool Peter Xu
2024-12-18 14:33 ` Ackerley Tng
2024-12-27 23:15 ` Ackerley Tng
2025-01-03 16:26 ` Peter Xu
2024-12-01 21:22 ` [PATCH 2/7] mm/hugetlb: Stop using avoid_reserve flag in fork() Peter Xu
2024-12-01 21:22 ` [PATCH 3/7] mm/hugetlb: Rename avoid_reserve to cow_from_owner Peter Xu
2024-12-01 21:22 ` [PATCH 4/7] mm/hugetlb: Clean up map/global resv accounting when allocate Peter Xu
2024-12-28 0:06 ` Ackerley Tng
2025-01-03 16:37 ` Peter Xu
2025-01-06 14:48 ` Ackerley Tng
2025-01-06 20:55 ` Peter Xu
2024-12-01 21:22 ` [PATCH 5/7] mm/hugetlb: Simplify vma_has_reserves() Peter Xu
2024-12-01 21:22 ` [PATCH 6/7] mm/hugetlb: Drop vma_has_reserves() Peter Xu
2024-12-01 21:22 ` [PATCH 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=20241201212240.533824-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