7365ff2c - mm/cma: export total and free number of pages for CMA areas

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

mm/cma: export total and free number of pages for CMA areasPatch series "hugetlb/CMA improvements for large systems", v5.On large systems, we observed some issues with hugetlb and CMA:1) When specifying a large number of hugetlb boot pages (hugepages= on the commandline), the kernel may run out of memory before it even gets to HVO. For example, if you have a 3072G system, and want to use 3024 1G hugetlb pages for VMs, that should leave you plenty of space for the hypervisor, provided you have the hugetlb vmemmap optimization (HVO) enabled. However, since the vmemmap pages are always allocated first, and then later in boot freed, you will actually run yourself out of memory before you can do HVO. This means not getting all the hugetlb pages you want, and worse, failure to boot if there is an allocation failure in the system from which it can't recover.2) There is a system setup where you might want to use hugetlb_cma with a large value (say, again, 3024 out of 3072G like above), and then lower that if system usage allows it, to make room for non-hugetlb processes. For this, a variation of the problem above applies: the kernel runs out of unmovable space to allocate from before you finish boot, since your CMA area takes up all the space.3) CMA wants to use one big contiguous area for allocations. Which fails if you have the aforementioned 3T system with a gap in the middle of physical memory (like the < 40bits BIOS DMA area seen on some AMD systems). You then won't be able to set up a CMA area for one of the NUMA nodes, leading to loss of half of your hugetlb CMA area.4) Under the scenario mentioned in 2), when trying to grow the number of hugetlb pages after dropping it for a while, new CMA allocations may fail occasionally. This is not unexpected, some transient references on pages may prevent cma_alloc from succeeding under memory pressure. However, the hugetlb code then falls back to a normal contiguous alloc, which may end up succeeding. This is not always desired behavior. If you have a large CMA area, then the kernel has a restricted amount of memory it can do unmovable allocations from (a well known issue). A normal contiguous alloc may eat further in to this space.To resolve these issues, do the following:* Add hooks to the section init code to do custom initialization of memmap pages. Hugetlb bootmem (memblock) allocated pages can then be pre-HVOed. This avoids allocating a large number of vmemmap pages early in boot, only to have them be freed again later, and also avoids running out of memory as described under 1). Using these hooks for hugetlb is optional. It requires moving hugetlb bootmem allocation to an earlier spot by the architecture. This has been enabled on x86.* hugetlb_cma doesn't care about the CMA area it uses being one large contiguous range. Multiple smaller ranges are fine. The only requirements are that the areas should be on one NUMA node, and individual gigantic pages should be allocatable from them. So, implement multi-range support for CMA, avoiding issue 3).* Introduce a hugetlb_cma_only option on the commandline. This only allows allocations from CMA for gigantic pages, if hugetlb_cma= is also specified.* With hugetlb_cma_only active, it also makes sense to be able to pre-allocate gigantic hugetlb pages at boot time from the CMA area(s). Add a rudimentary early CMA allocation interface, that just grabs a piece of memblock-allocated space from the CMA area, which gets marked as allocated in the CMA bitmap when the CMA area is initialized. With this, hugepages= can be supported with hugetlb_cma=, making scenario 2) work.Additionally, fix some minor bugs, with one worth mentioning: sincehugetlb gigantic bootmem pages are allocated by memblock, they may spanmultiple zones, as memblock doesn't (and mostly can't) know about zones. This can cause problems. A hugetlb page spanning multiple zones is bad,and it's worse with HVO, when the de-HVO step effectively sneakilyre-assigns pages to a different zone than originally configured, since thetail pages all inherit the zone from the first 60 tail pages. Thiscondition is not common, but can be easily reproduced using ZONE_MOVABLE. To fix this, add checks to see if gigantic bootmem pages intersect withmultiple zones, and do not use them if they do, giving them back to thepage allocator instead.The first patch is kind of along for the ride, except that maintaining anavailable_count for a CMA area is convenient for the multiple rangesupport.This patch (of 27):In addition to the number of allocations and releases, system managementsoftware may like to be aware of the size of CMA areas, and how many pagesare available in it. This information is currently not available, soexport it in total_page and available_pages, respectively.The name 'available_pages' was picked over 'free_pages' because 'free'implies that the pages are unused. But they might not be, they justhaven't been used by cma_allocThe number of available pages is tracked regardless of CONFIG_CMA_SYSFS,allowing for a few minor shortcuts in the code, avoiding bitmapoperations.Link: https://lkml.kernel.org/r/20250228182928.2645936-2-fvdl@google.comSigned-off-by: Frank van der Linden Reviewed-by: Oscar Salvador Cc: David Hildenbrand Cc: Joao Martins Cc: Muchun Song Cc: Roman Gushchin (Cruise) Cc: Usama Arif Cc: Yu Zhao Cc: Zi Yan Cc: Alexander Gordeev Cc: Andy Lutomirski Cc: Arnd Bergmann Cc: Dan Carpenter Cc: Dave Hansen Cc: Heiko Carstens Cc: Johannes Weiner Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Peter Zijlstra Cc: Vasily Gorbik Signed-off-by: Andrew Morton List of files: /linux-6.15/Documentation/ABI/testing/sysfs-kernel-mm-cma

b9ad003a - mm/cma: add sysfs file 'release_pages_success'

Tue, 06 Feb 2024 04:57:31 +0000

mm/cma: add sysfs file 'release_pages_success'This adds the following new sysfs file tracking the number of successfullyreleased pages from a given CMA heap area. This file will be availablevia CONFIG_CMA_SYSFS and help in determining active CMA pages available onthe CMA heap area. This adds a new 'nr_pages_released' (CONFIG_CMA_SYSFS)into 'struct cma' which gets updated during cma_release()./sys/kernel/mm/cma//release_pages_successAfter this change, an user will be able to find active CMA pages availablein a given CMA heap area via the following method.Active pages = alloc_pages_success - release_pages_successThat's valuable information for both software designers, and system adminsas it allows them to tune the number of CMA pages available in the system.This increases user visibility for allocated CMA area and itsutilization.Link: https://lkml.kernel.org/r/20240206045731.472759-1-anshuman.khandual@arm.comSigned-off-by: Anshuman Khandual Signed-off-by: Andrew Morton List of files: /linux-6.15/Documentation/ABI/testing/sysfs-kernel-mm-cma

43ca106f - mm: cma: support sysfs

Wed, 05 May 2021 01:37:28 +0000

mm: cma: support sysfsSince CMA is getting used more widely, it's more important to keepmonitoring CMA statistics for system health since it's directly related touser experience.This patch introduces sysfs statistics for CMA, in order to provide somebasic monitoring of the CMA allocator. * the number of CMA page successful allocations * the number of CMA page allocation failuresThese two values allow the user to calcuate the allocationfailure rate for each CMA area.e.g.) /sys/kernel/mm/cma/WIFI/alloc_pages_[success|fail] /sys/kernel/mm/cma/SENSOR/alloc_pages_[success|fail] /sys/kernel/mm/cma/BLUETOOTH/alloc_pages_[success|fail]The cma_stat was intentionally allocated by dynamic allocationto harmonize with kobject lifetime management.https://lore.kernel.org/linux-mm/YCOAmXqt6dZkCQYs@kroah.com/Link: https://lkml.kernel.org/r/20210324230759.2213957-1-minchan@kernel.orgLink: https://lore.kernel.org/linux-mm/20210316100433.17665-1-colin.king@canonical.com/Signed-off-by: Minchan Kim Signed-off-by: Colin Ian King Tested-by: Dmitry Osipenko Reviewed-by: Dmitry Osipenko Reviewed-by: Greg Kroah-Hartman Reviewed-by: John Hubbard Tested-by: Anders Roxell Cc: Suren Baghdasaryan Cc: John Dias Cc: Matthew Wilcox (Oracle) Cc: Colin Ian King Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds List of files: /linux-6.15/Documentation/ABI/testing/sysfs-kernel-mm-cma

Changes in sysfs-kernel-mm-cma

7365ff2c - mm/cma: export total and free number of pages for CMA areas

b9ad003a - mm/cma: add sysfs file 'release_pages_success'

43ca106f - mm: cma: support sysfs