Changes in Kconfig

6f110a5e - Disable SLUB_TINY for build testing

Sun, 06 Apr 2025 17:00:04 +0000

Disable SLUB_TINY for build testing... and don't error out so hard on missing module descriptions.Before commit 6c6c1fc09de3 ("modpost: require a MODULE_DESCRIPTION()")we used to warn about missing module descriptions, but only whenbuilding with extra warnigns (ie 'W=1').After that commit the warning became an unconditional hard error.And it turns out not all modules have been converted despite the claimsto the contrary. As reported by Damian Tometzki, the slub KUnit testdidn't have a module description, and apparently nobody ever reallynoticed.The reason nobody noticed seems to be that the slub KUnit tests getdisabled by SLUB_TINY, which also ends up disabling a lot of other code,both in tests and in slub itself. And so anybody doing full build testsdidn't actually see this failre.So let's disable SLUB_TINY for build-only tests, since it clearly endsup limiting build coverage. Also turn the missing module descriptionserror back into a warning, but let's keep it around for non-'W=1'builds.Reported-by: Damian Tometzki Link: https://lore.kernel.org/all/01070196099fd059-e8463438-7b1b-4ec8-816d-173874be9966-000000@eu-central-1.amazonses.com/Cc: Masahiro Yamada Cc: Jeff Johnson Fixes: 6c6c1fc09de3 ("modpost: require a MODULE_DESCRIPTION()")Signed-off-by: Linus Torvalds List of files: /linux-6.15/mm/Kconfig

e63ee43e - mm: CONFIG_NO_PAGE_MAPCOUNT to prepare for not maintain per-page mapcounts in large folios

Mon, 03 Mar 2025 16:30:08 +0000

mm: CONFIG_NO_PAGE_MAPCOUNT to prepare for not maintain per-page mapcounts in large foliosWe're close to the finishing line: let's introduce a newCONFIG_NO_PAGE_MAPCOUNT config option where we will incrementally removeany dependencies on per-page mapcounts in large folios. Once that's done,we'll stop maintaining the per-page mapcounts with this config optionenabled.CONFIG_NO_PAGE_MAPCOUNT will be EXPERIMENTAL for now, as we'll have tolearn about some of the real world impact of some of the implications.As writing "!CONFIG_NO_PAGE_MAPCOUNT" is really nasty, let's introduce ahelper config option "CONFIG_PAGE_MAPCOUNT" that expresses the negation.Link: https://lkml.kernel.org/r/20250303163014.1128035-16-david@redhat.comSigned-off-by: David Hildenbrand Cc: Andy Lutomirks^H^Hski Cc: Borislav Betkov Cc: Dave Hansen Cc: Ingo Molnar Cc: Jann Horn Cc: Johannes Weiner Cc: Jonathan Corbet Cc: Kirill A. Shutemov Cc: Lance Yang Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Matthew Wilcow (Oracle) Cc: Michal Koutn Cc: Muchun Song Cc: tejun heo Cc: Thomas Gleixner Cc: Vlastimil Babka Cc: Zefan Li Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Kconfig

6af8cb80 - mm/rmap: basic MM owner tracking for large folios (!hugetlb)

Mon, 03 Mar 2025 16:30:05 +0000

mm/rmap: basic MM owner tracking for large folios (!hugetlb)For small folios, we traditionally use the mapcount to decide whether itwas "certainly mapped exclusively" by a single MM (mapcount == 1) orwhether it "maybe mapped shared" by multiple MMs (mapcount > 1). ForPMD-sized folios that were PMD-mapped, we were able to use a similarmechanism (single PMD mapping), but for PTE-mapped folios and in thefuture folios that span multiple PMDs, this does not work.So we need a different mechanism to handle large folios. Let's add a newmechanism to detect whether a large folio is "certainly mappedexclusively", or whether it is "maybe mapped shared".We'll use this information next to optimize CoW reuse for PTE-mappedanonymous THP, and to convert folio_likely_mapped_shared() tofolio_maybe_mapped_shared(), independent of per-page mapcounts.For each large folio, we'll have two slots, whereby a slot stores: (1) an MM id: unique id assigned to each MM (2) a per-MM mapcountIf a slot is unoccupied, it can be taken by the next MM that maps foliopage.In addition, we'll remember the current state -- "mapped exclusively" vs. "maybe mapped shared" -- and use a bit spinlock to sync on updates and toreduce the total number of atomic accesses on updates. In the future, itmight be possible to squeeze a proper spinlock into "struct folio". Fornow, keep it simple, as we require the whole thing with THP only, that isincompatible with RT.As we have to squeeze this information into the "struct folio" of evenfolios of order-1 (2 pages), and we generally want to reduce the requiredmetadata, we'll assign each MM a unique ID that can fit into an int. Intotal, we can squeeze everything into 4x int (2x long) on 64bit.32bit support is a bit challenging, because we only have 2x long == 2x intin order-1 folios. But we can make it work for now, because we neitherexpect many MMs nor very large folios on 32bit.We will reliably detect folios as "mapped exclusively" vs. "mappedshared" as long as only two MMs map pages of a folio at one point in time-- for example with fork() and short-lived child processes, or with appsthat hand over state from one instance to another.As soon as three MMs are involved at the same time, we might detect "maybemapped shared" although the folio is "mapped exclusively".Example 1:(1) App1 faults in a (shmem/file-backed) folio page -> Tracked as MM0(2) App2 faults in a folio page -> Tracked as MM1(4) App1 unmaps all folio pages -> We will detect "mapped exclusively".Example 2:(1) App1 faults in a (shmem/file-backed) folio page -> Tracked as MM0(2) App2 faults in a folio page -> Tracked as MM1(3) App3 faults in a folio page -> No slot available, tracked as "unknown"(4) App1 and App2 unmap all folio pages -> We will detect "maybe mapped shared".Make use of __always_inline to keep possible performance degradation when(un)mapping large folios to a minimum.Note: by squeezing the two flags into the "unsigned long" that stores theMM ids, we can use non-atomic __bit_spin_unlock() and non-atomicsetting/clearing of the "maybe mapped shared" bit, effectively not addingany new atomics on the hot path when updating the large mapcount + newmetadata, which further helps reduce the runtime overhead inmicro-benchmarks.Link: https://lkml.kernel.org/r/20250303163014.1128035-13-david@redhat.comSigned-off-by: David Hildenbrand Cc: Andy Lutomirks^H^Hski Cc: Borislav Betkov Cc: Dave Hansen Cc: Ingo Molnar Cc: Jann Horn Cc: Johannes Weiner Cc: Jonathan Corbet Cc: Kirill A. Shutemov Cc: Lance Yang Cc: Liam Howlett Cc: Lorenzo Stoakes Cc: Matthew Wilcow (Oracle) Cc: Michal Koutn Cc: Muchun Song Cc: tejun heo Cc: Thomas Gleixner Cc: Vlastimil Babka Cc: Zefan Li Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Kconfig

d65917c4 - mm/sparse: allow for alternate vmemmap section init at boot

Fri, 28 Feb 2025 18:29:11 +0000

mm/sparse: allow for alternate vmemmap section init at bootAdd functions that are called just before the per-section memmap isinitialized and just before the memmap page structures are initialized. They are called sparse_vmemmap_init_nid_early andsparse_vmemmap_init_nid_late, respectively.This allows for mm subsystems to add calls to initialize memmap and pagestructures in a specific way, if using SPARSEMEM_VMEMMAP. Specifically,hugetlb can pre-HVO bootmem allocated pages that way, so that no time andresources are wasted on allocating vmemmap pages, only to free them later(and possibly unnecessarily running the system out of memory in theprocess).Refactor some code and export a few convenience functions for externaluse.In sparse_init_nid, skip any sections that are already initialized, e.g. they have been initialized by sparse_vmemmap_init_nid_early already.The hugetlb code to use these functions will be added in a later commit.Export section_map_size, as any alternate memmap init code will want touse it.The internal config option to enable this is SPARSEMEM_VMEMMAP_PREINIT,which is selected if an architecture-specific option,ARCH_WANT_HUGETLB_VMEMMAP_PREINIT, is set. In the future, if othersubsystems want to do preinit too, they can do it in a similar fashion.The internal config option is there because a section flag is used, andthe number of flags available is architecture-dependent (see mmzone.h). Architecures can decide if there is room for the flag when enablingoptions that select SPARSEMEM_VMEMMAP_PREINIT.Fortunately, as of right now, all sparse vmemmap using architectures dohave room.Link: https://lkml.kernel.org/r/20250228182928.2645936-11-fvdl@google.comSigned-off-by: Frank van der Linden Cc: Johannes Weiner Cc: Alexander Gordeev Cc: Andy Lutomirski Cc: Arnd Bergmann Cc: Dan Carpenter Cc: Dave Hansen Cc: David Hildenbrand Cc: Heiko Carstens Cc: Joao Martins Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Muchun Song Cc: Oscar Salvador Cc: Peter Zijlstra Cc: Roman Gushchin (Cruise) Cc: Usama Arif Cc: Vasily Gorbik Cc: Yu Zhao Cc: Zi Yan Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Kconfig

6df8bae8 - mm: zbud: remove zbud

Wed, 29 Jan 2025 18:06:32 +0000

mm: zbud: remove zbudThe zbud compressed pages allocator is rarely used, most users usezsmalloc. zbud consumes much more memory (only stores 1 or 2 compressedpages per physical page). The only advantage of zbud is a marginalperformance improvement that by no means justify the memory overhead.Historically, zsmalloc had significantly worse latency than zbud andz3fold but offered better memory savings. This is no longer the case asshown by a simple recent analysis [1]. In a kernel build test on tmpfs ina limited cgroup, zbud 2-3% less time than zsmalloc, but at the cost ofusing ~32% more memory (1.5G vs 1.13G). The tradeoff does not make sensefor zbud in any practical scenario.The only alleged advantage of zbud is not having the dependency onCONFIG_MMU, but CONFIG_SWAP already depends on CONFIG_MMU anyway, and zbudis only used by zswap.Remove zbud after z3fold's removal, leaving zsmalloc as the one and onlyzpool allocator. Leave the removal of the zpool API (and its associatedconfig options) to a followup cleanup after no more allocators show up.Deprecating zbud for a few cycles before removing it was initiallyproposed [2], like z3fold was marked as deprecated for 2 cycles [3]. However, Johannes rightfully pointed out that the 2 cycles is too shortfor most downstream consumers, and z3fold was deprecated first only as acourtesy anyway.[1]https://lore.kernel.org/lkml/CAJD7tkbRF6od-2x_L8-A1QL3=2Ww13sCj4S3i4bNndqF+3+_Vg@mail.gmail.com/[2]https://lore.kernel.org/lkml/Z5gdnSX5Lv-nfjQL@google.com/[3]https://lore.kernel.org/lkml/20240904233343.933462-1-yosryahmed@google.com/Link: https://lkml.kernel.org/r/20250129180633.3501650-3-yosry.ahmed@linux.devSigned-off-by: Yosry Ahmed Reviewed-by: Shakeel Butt Acked-by: Johannes Weiner Acked-by: Nhat Pham Cc: Alexander Gordeev Cc: Chengming Zhou Cc: Christian Borntraeger Cc: Dan Streetman Cc: Heiko Carstens Cc: Huacai Chen Cc: Miaohe Lin Cc: Seth Jennings Cc: Sven Schnelle Cc: Vasily Gorbik Cc: Vitaly Wool Cc: Vlastimil Babka Cc: WANG Xuerui Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Kconfig

58ba73e5 - mm: z3fold: remove z3fold

Wed, 29 Jan 2025 18:06:31 +0000

mm: z3fold: remove z3foldPatch series "mm: zswap: remove z3fold and zbud", v2.After 2 cycles of deprecating z3fold, remove it as well as zbud (rationalein specific patches).This patch (of 2):Z3fold has been marked as deprecated for 2 cycles and no one complained,as expected. As there are no known users, remove the code now.Link: https://lkml.kernel.org/r/20250129180633.3501650-1-yosry.ahmed@linux.devLink: https://lkml.kernel.org/r/20250129180633.3501650-2-yosry.ahmed@linux.devSigned-off-by: Yosry Ahmed Acked-by: Johannes Weiner Reviewed-by: Shakeel Butt Acked-by: Nhat Pham Cc: Alexander Gordeev Cc: Chengming Zhou Cc: Christian Borntraeger Cc: Dan Streetman Cc: Heiko Carstens Cc: Huacai Chen Cc: Miaohe Lin Cc: Seth Jennings Cc: Sven Schnelle Cc: Vasily Gorbik Cc: Vitaly Wool Cc: Vlastimil Babka Cc: WANG Xuerui Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Kconfig

c9f8f124 - slab: don't batch kvfree_rcu() with SLUB_TINY

Mon, 03 Feb 2025 09:28:50 +0000

slab: don't batch kvfree_rcu() with SLUB_TINYkvfree_rcu() is batched for better performance except on TINY_RCU, whichis a simple implementation for small UP systems. Similarly SLUB_TINY isan option intended for small systems, whether or not used together withTINY_RCU. In case SLUB_TINY is used with !TINY_RCU, it makes arguablysense to not do the batching and limit the memory footprint. It's alsosuboptimal to have RCU-specific #ifdefs in slab code.With that, add CONFIG_KVFREE_RCU_BATCHED to determine whether batchingkvfree_rcu() implementation is used. It is not set by a user prompt, butenabled by default and disabled in case TINY_RCU or SLUB_TINY areenabled.Use the new config for #ifdef's in slab code and extend their scope tocover all code used by the batched kvfree_rcu(). For example there's noneed to perform kvfree_rcu_init() if the batching is disabled.Reviewed-by: Uladzislau Rezki (Sony) Reviewed-by: Joel Fernandes (Google) Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>Tested-by: Paul E. McKenney Signed-off-by: Vlastimil Babka List of files: /linux-6.15/mm/Kconfig

44d46b76 - mm: add build-time option for hotplug memory default online type

Fri, 20 Dec 2024 21:07:09 +0000

mm: add build-time option for hotplug memory default online typeMemory hotplug presently auto-onlines memory into a zone the kernel deemsappropriate if CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y.The memhp_default_state boot param enables runtime config, but it's notpossible to do this at build-time.Remove CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE, and replace it withCONFIG_MHP_DEFAULT_ONLINE_TYPE_* choices that sync with the boot param.Selections: CONFIG_MHP_DEFAULT_ONLINE_TYPE_OFFLINE => mhp_default_online_type = "offline" Memory will not be onlined automatically. CONFIG_MHP_DEFAULT_ONLINE_TYPE_ONLINE_AUTO => mhp_default_online_type = "online" Memory will be onlined automatically in a zone deemed. appropriate by the kernel. CONFIG_MHP_DEFAULT_ONLINE_TYPE_ONLINE_KERNEL => mhp_default_online_type = "online_kernel" Memory will be onlined automatically. The zone may allow kernel data (e.g. ZONE_NORMAL). CONFIG_MHP_DEFAULT_ONLINE_TYPE_ONLINE_MOVABLE => mhp_default_online_type = "online_movable" Memory will be onlined automatically. The zone will be ZONE_MOVABLE.Default to CONFIG_MHP_DEFAULT_ONLINE_TYPE_OFFLINE to match the existingdefault CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=n behavior.Existing users of CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y should useCONFIG_MHP_DEFAULT_ONLINE_TYPE_ONLINE_AUTO.[gourry@gourry.net: update KConfig comments] Link: https://lkml.kernel.org/r/20241226182918.648799-1-gourry@gourry.netLink: https://lkml.kernel.org/r/20241220210709.300066-1-gourry@gourry.netSigned-off-by: Gregory Price Acked-by: David Hildenbrand Cc: Greg Kroah-Hartman Cc: Huacai Chen Cc: Jonathan Corbet Cc: Oscar Salvador Cc: "Rafael J. Wysocki" Cc: WANG Xuerui Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Kconfig

6375e95f - mm: pgtable: reclaim empty PTE page in madvise(MADV_DONTNEED)

Wed, 04 Dec 2024 11:09:49 +0000

mm: pgtable: reclaim empty PTE page in madvise(MADV_DONTNEED)Now in order to pursue high performance, applications mostly use somehigh-performance user-mode memory allocators, such as jemalloc ortcmalloc. These memory allocators use madvise(MADV_DONTNEED or MADV_FREE)to release physical memory, but neither MADV_DONTNEED nor MADV_FREE willrelease page table memory, which may cause huge page table memory usage.The following are a memory usage snapshot of one process which actuallyhappened on our server: VIRT: 55t RES: 590g VmPTE: 110gIn this case, most of the page table entries are empty. For such a PTEpage where all entries are empty, we can actually free it back to thesystem for others to use.As a first step, this commit aims to synchronously free the empty PTEpages in madvise(MADV_DONTNEED) case. We will detect and free empty PTEpages in zap_pte_range(), and will add zap_details.reclaim_pt to excludecases other than madvise(MADV_DONTNEED).Once an empty PTE is detected, we first try to hold the pmd lock withinthe pte lock. If successful, we clear the pmd entry directly (fast path).Otherwise, we wait until the pte lock is released, then re-hold the pmdand pte locks and loop PTRS_PER_PTE times to check pte_none() to re-detectwhether the PTE page is empty and free it (slow path).For other cases such as madvise(MADV_FREE), consider scanning and freeingempty PTE pages asynchronously in the future.The following code snippet can show the effect of optimization: mmap 50G while (1) { for (; i < 1024 * 25; i++) { touch 2M memory madvise MADV_DONTNEED 2M } }As we can see, the memory usage of VmPTE is reduced: before afterVIRT 50.0 GB 50.0 GBRES 3.1 MB 3.1 MBVmPTE 102640 KB 240 KB[zhengqi.arch@bytedance.com: fix uninitialized symbol 'ptl'] Link: https://lkml.kernel.org/r/20241206112348.51570-1-zhengqi.arch@bytedance.com Link: https://lore.kernel.org/linux-mm/224e6a4e-43b5-4080-bdd8-b0a6fb2f0853@stanley.mountain/Link: https://lkml.kernel.org/r/92aba2b319a734913f18ba41e7d86a265f0b84e2.1733305182.git.zhengqi.arch@bytedance.comSigned-off-by: Qi Zheng Cc: Andy Lutomirski Cc: Catalin Marinas Cc: Dave Hansen Cc: David Hildenbrand Cc: David Rientjes Cc: Hugh Dickins Cc: Jann Horn Cc: Lorenzo Stoakes Cc: Matthew Wilcox Cc: Mel Gorman Cc: Muchun Song Cc: Peter Xu Cc: Peter Zijlstra Cc: Will Deacon Cc: Zach O'Keefe Cc: Dan Carpenter Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Kconfig

b7c5f9a1 - resource: remove dependency on SPARSEMEM from GET_FREE_REGION

Tue, 15 Oct 2024 05:15:54 +0000

resource: remove dependency on SPARSEMEM from GET_FREE_REGIONWe want to use the functions (get_free_mem_region()) configured viaGET_FREE_REGION in resource kunit tests. However, GET_FREE_REGIONdepends on SPARSEMEM now. This makes resource kunit tests cannot bebuilt on some architectures lacking SPARSEMEM, or causes config warningas follows, WARNING: unmet direct dependencies detected for GET_FREE_REGION Depends on [n]: SPARSEMEM [=n] Selected by [y]: - RESOURCE_KUNIT_TEST [=y] && RUNTIME_TESTING_MENU [=y] && KUNIT [=y]When get_free_mem_region() was introduced the only consumers were thoselooking to pass the address range to memremap_pages(). That addressrange needed to be mindful of the maximum addressable platform physicaladdress which at the time only SPARSMEM defined via MAX_PHYSMEM_BITS.Given that memremap_pages() also depended on SPARSEMEM via ZONE_DEVICE,it was easier to just depend on that definition than invent a generalMAX_PHYSMEM_BITS concept outside of SPARSEMEM.Turns out that decision was buggy and did not account for KASANconsumption of physical address space. That problem was resolvedrecently with commit ea72ce5da228 ("x86/kaslr: Expose and use the endof the physical memory address space"), and GET_FREE_REGION dropped itsMAX_PHYSMEM_BITS dependency.Then commit 99185c10d5d9 ("resource, kunit: add test case forregion_intersects()"), went ahead and fixed up the only remainingdependency on SPARSEMEM which was usage of the PA_SECTION_SHIFT macrofor setting the default alignment. A PAGE_SIZE fallback is fine in theSPARSEMEM=n case.With those build dependencies gone GET_FREE_REGION no longer depends onSPARSEMEM. So, the patch removes dependency on SPARSEMEM fromGET_FREE_REGION to fix the build issues.Link: https://lkml.kernel.org/r/20241016014730.339369-1-ying.huang@intel.comLink: https://lore.kernel.org/lkml/20240922225041.603186-1-linux@roeck-us.net/Link: https://lkml.kernel.org/r/20241015051554.294734-1-ying.huang@intel.comFixes: 99185c10d5d9 ("resource, kunit: add test case for region_intersects()")Signed-off-by: "Huang, Ying" Co-developed-by: Dan Williams Signed-off-by: Dan Williams Tested-by: Guenter Roeck Acked-by: David Hildenbrand Tested-by: Nathan Chancellor # buildCc: Arnd Bergmann Cc: Jonathan Cameron Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Kconfig

bcc9d04e - mm: Introduce ARCH_HAS_USER_SHADOW_STACK

Tue, 01 Oct 2024 22:58:40 +0000

mm: Introduce ARCH_HAS_USER_SHADOW_STACKSince multiple architectures have support for shadow stacks and we need toselect support for this feature in several places in the generic codeprovide a generic config option that the architectures can select.Suggested-by: David Hildenbrand Acked-by: David Hildenbrand Reviewed-by: Deepak Gupta Reviewed-by: Rick Edgecombe Reviewed-by: Mike Rapoport (IBM) Reviewed-by: Catalin Marinas Reviewed-by: Kees Cook Tested-by: Kees Cook Acked-by: Shuah Khan Reviewed-by: Thiago Jung Bauermann Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20241001-arm64-gcs-v13-1-222b78d87eee@kernel.orgSigned-off-by: Catalin Marinas List of files: /linux-6.15/mm/Kconfig

a3344078 - mm: make SPLIT_PTE_PTLOCKS depend on SMP

Tue, 24 Sep 2024 15:42:05 +0000

mm: make SPLIT_PTE_PTLOCKS depend on SMPSPLIT_PTE_PTLOCKS depends on "NR_CPUS >= 4". Unfortunately, thatevaluates to true if there is no NR_CPUS configuration option. Thisresults in CONFIG_SPLIT_PTE_PTLOCKS=y for mac_defconfig. This in turncauses the m68k "q800" and "virt" machines to crash in qemu if debuggingoptions are enabled.Making CONFIG_SPLIT_PTE_PTLOCKS dependent on the existence of NR_CPUS doesnot work since a dependency on the existence of a numeric Kconfig entryalways evaluates to false. Example:config HAVE_NO_NR_CPUS def_bool y depends on !NR_CPUSAfter adding this to a Kconfig file, "make defconfig" includes:$ grep NR_CPUS .configCONFIG_NR_CPUS=64CONFIG_HAVE_NO_NR_CPUS=yDefining NR_CPUS for m68k does not help either since many architecturesdefine NR_CPUS only for SMP configurations.Make SPLIT_PTE_PTLOCKS depend on SMP instead to solve the problem.Link: https://lkml.kernel.org/r/20240924154205.1491376-1-linux@roeck-us.netFixes: 394290cba966 ("mm: turn USE_SPLIT_PTE_PTLOCKS / USE_SPLIT_PTE_PTLOCKS into Kconfig options")Signed-off-by: Guenter Roeck Acked-by: David Hildenbrand Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Kconfig

7a2369b7 - mm: z3fold: deprecate CONFIG_Z3FOLD

Wed, 04 Sep 2024 23:33:43 +0000

mm: z3fold: deprecate CONFIG_Z3FOLDThe z3fold compressed pages allocator is rarely used, most users usezsmalloc. The only disadvantage of zsmalloc in comparison is thedependency on MMU, and zbud is a more common option for !MMU as it was thedefault zswap allocator for a long time.Historically, zsmalloc had worse latency than zbud and z3fold but offeredbetter memory savings. This is no longer the case as shown by a simplerecent analysis [1]. That analysis showed that z3fold does not have anyadvantage over zsmalloc or zbud considering both performance and memoryusage. In a kernel build test on tmpfs in a limited cgroup, z3fold took3% more time and used 1.8% more memory. The latency of zswap_load() was7% higher, and that of zswap_store() was 10% higher. Zsmalloc is betterin all metrics.Moreover, z3fold apparently has latent bugs, which was made noticeable bya recent soft lockup bug report with z3fold [2]. Switching to zsmallocnot only fixed the problem, but also reduced the swap usage from 6~8G to1~2G. Other users have also reported being bitten by mistakenly enablingz3fold.Other than hurting users, z3fold is repeatedly causing wasted engineeringeffort. Apart from investigating the above bug, it came up in multipledevelopment discussions (e.g. [3]) as something we need to handle, whenthere aren't any legit users (at least not intentionally).The natural course of action is to deprecate z3fold, and remove in a fewcycles if no objections are raised from active users. Next on the listshould be zbud, as it offers marginal latency gains at the cost of hugememory waste when compared to zsmalloc. That one will need to wait untilzsmalloc does not depend on MMU.Rename the user-visible config option from CONFIG_Z3FOLD toCONFIG_Z3FOLD_DEPRECATED so that users with CONFIG_Z3FOLD=y get a newprompt with explanation during make oldconfig. Also, removeCONFIG_Z3FOLD=y from defconfigs.[1]https://lore.kernel.org/lkml/CAJD7tkbRF6od-2x_L8-A1QL3=2Ww13sCj4S3i4bNndqF+3+_Vg@mail.gmail.com/[2]https://lore.kernel.org/lkml/EF0ABD3E-A239-4111-A8AB-5C442E759CF3@gmail.com/[3]https://lore.kernel.org/lkml/CAJD7tkbnmeVugfunffSovJf9FAgy9rhBVt_tx=nxUveLUfqVsA@mail.gmail.com/[arnd@arndb.de: deprecate ZSWAP_ZPOOL_DEFAULT_Z3FOLD as well] Link: https://lkml.kernel.org/r/20240909202625.1054880-1-arnd@kernel.orgLink: https://lkml.kernel.org/r/20240904233343.933462-1-yosryahmed@google.comSigned-off-by: Yosry Ahmed Signed-off-by: Arnd Bergmann Acked-by: Chris Down Acked-by: Nhat Pham Acked-by: Johannes Weiner Acked-by: Vitaly Wool Acked-by: Christoph Hellwig Cc: Aneesh Kumar K.V Cc: Christophe Leroy Cc: Huacai Chen Cc: Miaohe Lin Cc: Michael Ellerman Cc: Naveen N. Rao Cc: Nicholas Piggin Cc: Sergey Senozhatsky Cc: WANG Xuerui Cc: Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Kconfig

6857be5f - mm: introduce ARCH_SUPPORTS_HUGE_PFNMAP and special bits to pmd/pud

Mon, 26 Aug 2024 20:43:35 +0000

mm: introduce ARCH_SUPPORTS_HUGE_PFNMAP and special bits to pmd/pudPatch series "mm: Support huge pfnmaps", v2.Overview========This series implements huge pfnmaps support for mm in general. Hugepfnmap allows e.g. VM_PFNMAP vmas to map in either PMD or PUD levels,similar to what we do with dax / thp / hugetlb so far to benefit from TLBhits. Now we extend that idea to PFN mappings, e.g. PCI MMIO bars whereit can grow as large as 8GB or even bigger.Currently, only x86_64 (1G+2M) and arm64 (2M) are supported. The lastpatch (from Alex Williamson) will be the first user of huge pfnmap, so asto enable vfio-pci driver to fault in huge pfn mappings.Implementation==============In reality, it's relatively simple to add such support comparing to manyother types of mappings, because of PFNMAP's specialties when there's novmemmap backing it, so that most of the kernel routines on huge mappingsshould simply already fail for them, like GUPs or old-school follow_page()(which is recently rewritten to be folio_walk* APIs by David).One trick here is that we're still unmature on PUDs in generic paths hereand there, as DAX is so far the only user. This patchset will add the 2nduser of it. Hugetlb can be a 3rd user if the hugetlb unification work cango on smoothly, but to be discussed later.The other trick is how to allow gup-fast working for such huge mappingseven if there's no direct sign of knowing whether it's a normal page orMMIO mapping. This series chose to keep the pte_special solution, so thatit reuses similar idea on setting a special bit to pfnmap PMDs/PUDs sothat gup-fast will be able to identify them and fail properly.Along the way, we'll also notice that the major pgtable pfn walker, aka,follow_pte(), will need to retire soon due to the fact that it only workswith ptes. A new set of simple API is introduced (follow_pfnmap* API) tobe able to do whatever follow_pte() can already do, plus that it can alsoprocess huge pfnmaps now. Half of this series is about that andconverting all existing pfnmap walkers to use the new API properly. Hopefully the new API also looks better to avoid exposing e.g. pgtablelock details into the callers, so that it can be used in an even morestraightforward way.Here, three more options will be introduced and involved in huge pfnmap: - ARCH_SUPPORTS_HUGE_PFNMAP Arch developers will need to select this option when huge pfnmap is supported in arch's Kconfig. After this patchset applied, both x86_64 and arm64 will start to enable it by default. - ARCH_SUPPORTS_PMD_PFNMAP / ARCH_SUPPORTS_PUD_PFNMAP These options are for driver developers to identify whether current arch / config supports huge pfnmaps, making decision on whether it can use the huge pfnmap APIs to inject them. One can refer to the last vfio-pci patch from Alex on the use of them properly in a device driver.So after the whole set applied, and if one would enable some dynamic debuglines in vfio-pci core files, we should observe things like: vfio-pci 0000:00:06.0: vfio_pci_mmap_huge_fault(,order = 9) BAR 0 page offset 0x0: 0x100 vfio-pci 0000:00:06.0: vfio_pci_mmap_huge_fault(,order = 9) BAR 0 page offset 0x200: 0x100 vfio-pci 0000:00:06.0: vfio_pci_mmap_huge_fault(,order = 9) BAR 0 page offset 0x400: 0x100In this specific case, it says that vfio-pci faults in PMDs properly for afew BAR0 offsets.Patch Layout============Patch 1: Introduce the new options mentioned above for huge PFNMAPsPatch 2: A tiny cleanupPatch 3-8: Preparation patches for huge pfnmap (include introduce special bit for pmd/pud)Patch 9-16: Introduce follow_pfnmap*() API, use it everywhere, and then drop follow_pte() APIPatch 17: Add huge pfnmap support for x86_64Patch 18: Add huge pfnmap support for arm64Patch 19: Add vfio-pci support for all kinds of huge pfnmaps (Alex)TODO====More architectures / More page sizes------------------------------------Currently only x86_64 (2M+1G) and arm64 (2M) are supported. There seemsto have plan to support arm64 1G later on top of this series [2].Any arch will need to first support THP / THP_1G, then provide a specialbit in pmds/puds to support huge pfnmaps.remap_pfn_range() support-------------------------Currently, remap_pfn_range() still only maps PTEs. With the new option,remap_pfn_range() can logically start to inject either PMDs or PUDs whenthe alignment requirements match on the VAs.When the support is there, it should be able to silently benefit alldrivers that is using remap_pfn_range() in its mmap() handler on betterTLB hit rate and overall faster MMIO accesses similar to processor onhugepages.More driver support-------------------VFIO is so far the only consumer for the huge pfnmaps after this seriesapplied. Besides above remap_pfn_range() generic optimization, devicedriver can also try to optimize its mmap() on a better VA alignment foreither PMD/PUD sizes. This may, iiuc, normally require userspace changes,as the driver doesn't normally decide the VA to map a bar. But I don'tthink I know all the drivers to know the full picture.Credits all go to Alex on help testing the GPU/NIC use cases above.[0] https://lore.kernel.org/r/73ad9540-3fb8-4154-9a4f-30a0a2b03d41@lucifer.local[1] https://lore.kernel.org/r/20240807194812.819412-1-peterx@redhat.com[2] https://lore.kernel.org/r/498e0731-81a4-4f75-95b4-a8ad0bcc7665@huawei.comThis patch (of 19):This patch introduces the option to introduce special pte bit intopmd/puds. Archs can start to define pmd_special / pud_special whensupported by selecting the new option. Per-arch support will be addedlater.Before that, create fallbacks for these helpers so that they are alwaysavailable.Link: https://lkml.kernel.org/r/20240826204353.2228736-1-peterx@redhat.comLink: https://lkml.kernel.org/r/20240826204353.2228736-2-peterx@redhat.comSigned-off-by: Peter Xu Cc: Alexander Gordeev Cc: Alex Williamson Cc: Aneesh Kumar K.V Cc: Borislav Petkov Cc: Catalin Marinas Cc: Christian Borntraeger Cc: Dave Hansen Cc: David Hildenbrand Cc: Gavin Shan Cc: Gerald Schaefer Cc: Heiko Carstens Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Matthew Wilcox Cc: Niklas Schnelle Cc: Paolo Bonzini Cc: Ryan Roberts Cc: Sean Christopherson Cc: Sven Schnelle Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Will Deacon Cc: Zi Yan Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Kconfig

5ad7a998 - mm: Kconfig: fixup zsmalloc configuration

Tue, 03 Sep 2024 04:00:22 +0000

mm: Kconfig: fixup zsmalloc configurationzsmalloc is not exclusive to zswap. Commit b3fbd58fcbb1 ("mm: Kconfig:simplify zswap configuration") made CONFIG_ZSMALLOC only visible whenCONFIG_ZSWAP is selected, which makes it impossible to menuconfigzsmalloc-specific features (stats, chain-size, etc.) on systems that useZRAM but don't have ZSWAP enabled.Make zsmalloc depend on both ZRAM and ZSWAP.Link: https://lkml.kernel.org/r/20240903040143.1580705-1-senozhatsky@chromium.orgFixes: b3fbd58fcbb1 ("mm: Kconfig: simplify zswap configuration") Signed-off-by: Sergey Senozhatsky Cc: Johannes Weiner Cc: Minchan Kim Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Kconfig

7a87225a - x86: remove PG_uncached

Wed, 21 Aug 2024 19:34:43 +0000

x86: remove PG_uncachedConvert x86 to use PG_arch_2 instead of PG_uncached and removePG_uncached.Link: https://lkml.kernel.org/r/20240821193445.2294269-11-willy@infradead.orgSigned-off-by: Matthew Wilcox (Oracle) Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Kconfig

04cb7502 - zsmalloc: use all available 24 bits of page_type

Wed, 21 Aug 2024 17:39:12 +0000

zsmalloc: use all available 24 bits of page_typeNow that we have an extra 8 bits, we don't need to limit ourselves tosupporting a 64KiB page size. I'm sure both Hexagon users are grateful,but it does reduce complexity a little. We can also removereset_first_obj_offset() as calling __ClearPageZsmalloc() will now resetall 32 bits of page_type.Link: https://lkml.kernel.org/r/20240821173914.2270383-5-willy@infradead.orgSigned-off-by: Matthew Wilcox (Oracle) Acked-by: David Hildenbrand Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>Cc: Kent Overstreet Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Kconfig

b0c4e27c - mm: introduce numa_emulation

Wed, 07 Aug 2024 06:41:03 +0000

mm: introduce numa_emulationMove numa_emulation code from arch/x86 to mm/numa_emulation.cThis code will be later reused by arch_numa.No functional changes.Link: https://lkml.kernel.org/r/20240807064110.1003856-20-rppt@kernel.orgSigned-off-by: Mike Rapoport (Microsoft) Tested-by: Zi Yan # for x86_64 and arm64Reviewed-by: Jonathan Cameron Tested-by: Jonathan Cameron [arm64 + CXL via QEMU]Acked-by: Dan Williams Cc: Alexander Gordeev Cc: Andreas Larsson Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Catalin Marinas Cc: Christophe Leroy Cc: Dave Hansen Cc: David Hildenbrand Cc: Davidlohr Bueso Cc: David S. Miller Cc: Greg Kroah-Hartman Cc: Heiko Carstens Cc: Huacai Chen Cc: Ingo Molnar Cc: Jiaxun Yang Cc: John Paul Adrian Glaubitz Cc: Jonathan Corbet Cc: Michael Ellerman Cc: Palmer Dabbelt Cc: Rafael J. Wysocki Cc: Rob Herring (Arm) Cc: Samuel Holland Cc: Thomas Bogendoerfer Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Will Deacon Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Kconfig

87482708 - mm: introduce numa_memblks

Wed, 07 Aug 2024 06:41:01 +0000

mm: introduce numa_memblksMove code dealing with numa_memblks from arch/x86 to mm/ and add Kconfigoptions to let x86 select it in its Kconfig.This code will be later reused by arch_numa.No functional changes.Link: https://lkml.kernel.org/r/20240807064110.1003856-18-rppt@kernel.orgSigned-off-by: Mike Rapoport (Microsoft) Tested-by: Zi Yan # for x86_64 and arm64Reviewed-by: Jonathan Cameron Tested-by: Jonathan Cameron [arm64 + CXL via QEMU]Acked-by: Dan Williams Acked-by: David Hildenbrand Cc: Alexander Gordeev Cc: Andreas Larsson Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Catalin Marinas Cc: Christophe Leroy Cc: Dave Hansen Cc: Davidlohr Bueso Cc: David S. Miller Cc: Greg Kroah-Hartman Cc: Heiko Carstens Cc: Huacai Chen Cc: Ingo Molnar Cc: Jiaxun Yang Cc: John Paul Adrian Glaubitz Cc: Jonathan Corbet Cc: Michael Ellerman Cc: Palmer Dabbelt Cc: Rafael J. Wysocki Cc: Rob Herring (Arm) Cc: Samuel Holland Cc: Thomas Bogendoerfer Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Will Deacon Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Kconfig

394290cb - mm: turn USE_SPLIT_PTE_PTLOCKS / USE_SPLIT_PTE_PTLOCKS into Kconfig options

Fri, 26 Jul 2024 15:07:26 +0000

mm: turn USE_SPLIT_PTE_PTLOCKS / USE_SPLIT_PTE_PTLOCKS into Kconfig optionsPatch series "mm: split PTE/PMD PT table Kconfig cleanups+clarifications".This series is a follow up to the fixes: "[PATCH v1 0/2] mm/hugetlb: fix hugetlb vs. core-mm PT locking"When working on the fixes, I wondered why 8xx is fine (-> never uses splitPT locks) and how PT locking even works properly with PMD page tablesharing (-> always requires split PMD PT locks).Let's improve the split PT lock detection, make hugetlb properly depend onit and make 8xx bail out if it would ever get enabled by accident.As an alternative to patch #3 we could extend the KconfigSPLIT_PTE_PTLOCKS option from patch #2 -- but enforcing it closer to thecode that actually implements it feels a bit nicer for documentationpurposes, and there is no need to actually disable it because it shouldalways be disabled (!SMP).Did a bunch of cross-compilations to make sure that split PTE/PMD PT locksare still getting used where we would expect them.[1] https://lkml.kernel.org/r/20240725183955.2268884-1-david@redhat.comThis patch (of 3):Let's clean that up a bit and prepare for depending onCONFIG_SPLIT_PMD_PTLOCKS in other Kconfig options.More cleanups would be reasonable (like the arch-specific "depends on" forCONFIG_SPLIT_PTE_PTLOCKS), but we'll leave that for another day.Link: https://lkml.kernel.org/r/20240726150728.3159964-1-david@redhat.comLink: https://lkml.kernel.org/r/20240726150728.3159964-2-david@redhat.comSigned-off-by: David Hildenbrand Acked-by: Mike Rapoport (Microsoft) Reviewed-by: Russell King (Oracle) Reviewed-by: Qi Zheng Cc: Alexander Viro Cc: Borislav Petkov Cc: Boris Ostrovsky Cc: Christian Brauner Cc: Christophe Leroy Cc: Dave Hansen Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Juergen Gross Cc: Michael Ellerman Cc: Muchun Song Cc: "Naveen N. Rao" Cc: Nicholas Piggin Cc: Oscar Salvador Cc: Peter Xu Cc: Thomas Gleixner Signed-off-by: Andrew Morton List of files: /linux-6.15/mm/Kconfig