On 23.07.24 23:04, Peter Xu wrote:
On Tue, Jul 23, 2024 at 10:18:37AM +0200, David Hildenbrand wrote:
On 22.07.24 17:31, Peter Xu wrote:
On Mon, Jul 22, 2024 at 03:29:43PM +0200, David Hildenbrand wrote:
On 18.07.24 00:02, Peter Xu wrote:
This is an RFC series, so not yet for merging. Please don't be scared by
the code changes: most of them are code movements only.
This series is based on the dax mprotect fix series here (while that one is
based on mm-unstable):
[PATCH v3 0/8] mm/mprotect: Fix dax puds
https://lore.kernel.org/r/20240715192142.3241557-1-peterx@xxxxxxxxxx
Overview
========
This series doesn't provide any feature change. The only goal of this
series is to start decoupling two ideas: "THP" and "huge mapping". We
already started with having PGTABLE_HAS_HUGE_LEAVES config option, and this
one extends that idea into the code.
The issue is that we have so many functions that only compile with
CONFIG_THP=on, even though they're about huge mappings, and huge mapping is
a pretty common concept, which can apply to many things besides THPs
nowadays. The major THP file is mm/huge_memory.c as of now.
The first example of such huge mapping users will be hugetlb. We lived
until now with no problem simply because Linux almost duplicated all the
logics there in the "THP" files into hugetlb APIs. If we want to get rid
of hugetlb specific APIs and paths, this _might_ be the first thing we want
to do, because we want to be able to e.g., zapping a hugetlb pmd entry even
if !CONFIG_THP.
Then consider other things like dax / pfnmaps. Dax can depend on THP, then
it'll naturally be able to use pmd/pud helpers, that's okay. However is it
a must? Do we also want to have every new pmd/pud mappings in the future
to depend on THP (like PFNMAP)? My answer is no, but I'm open to opinions.
If anyone agrees with me that "huge mapping" (aka, PMD/PUD mappings that
are larger than PAGE_SIZE) is a more generic concept than THP, then I think
at some point we need to move the generic code out of THP code into a
common code base.
This is what this series does as a start.
Hi Peter!
From a quick glimpse, patch #1-#4 do make sense independent of patch #5.
I am not so sure about all of the code movement in patch #5. If large folios
are the future, then likely huge_memory.c should simply be the home for all
that logic.
Maybe the goal should better be to compile huge_memory.c not only for THP,
but also for other use cases that require that logic, and fence off all THP
specific stuff using #ifdef?
Not sure, though. But a lot of this code movements/churn might be avoidable.
I'm fine using ifdefs in the current fine, but IMHO it's a matter of
whether we want to keep huge_memory.c growing into even larger file, and
keep all large folio logics only in that file. Currently it's ~4000 LOCs.
Depends on "how much" for sure. huge_memory.c is currently on place 12 of
the biggest files in mm/. So there might not be immediate cause for action
... just yet :) [guess which file is on #2 :) ]
7821, hugetlb.c
7602, vmscan.c
7275, slub.c
7072, page_alloc.c
6673, memory.c
5402, memcontrol.c
5239, shmem.c
5155, vmalloc.c
4419, filemap.c
4060, mmap.c
3882, huge_memory.c
IMHO a split is normally better than keeping everything in one file, but
yeah I'd confess THP file isn't that bad comparing to others.. And I'm
definitely surprised it's even out of top ten.
It's always interesting looking at the numbers here. For v6.10 we had:
8521 mm/memcontrol.c
7813 mm/hugetlb.c
7550 mm/vmscan.c
7266 mm/slub.c
7018 mm/page_alloc.c
6468 mm/memory.c
5154 mm/vmalloc.c
5002 mm/shmem.c
4419 mm/filemap.c
4019 mm/mmap.c
3954 mm/ksm.c
3740 mm/swapfile.c
3730 mm/huge_memory.c
3689 mm/gup.c
3542 mm/mempolicy.c
I suspect memcontrol.c shrunk because of the v1 split-off, leaving
hugetlb.c now at #1 :)
--
Cheers,
David / dhildenb
