- Linux-stable-mirror - lists.linaro.org

[PATCH v2] mm: memory-tiering: fix PGPROMOTE_CANDIDATE counting

by Ruan Shiyang

Goto-san reported confusing pgpromote statistics where the pgpromote_success count significantly exceeded pgpromote_candidate. On a system with three nodes (nodes 0-1: DRAM 4GB, node 2: NVDIMM 4GB): # Enable demotion only echo 1 > /sys/kernel/mm/numa/demotion_enabled numactl -m 0-1 memhog -r200 3500M >/dev/null & pid=$! sleep 2 numactl memhog -r100 2500M >/dev/null & sleep 10 kill -9 $pid # terminate the 1st memhog # Enable promotion echo 2 > /proc/sys/kernel/numa_balancing After a few seconds, we observeed `pgpromote_candidate < pgpromote_success` $ grep -e pgpromote /proc/vmstat pgpromote_success 2579 pgpromote_candidate 0 In this scenario, after terminating the first memhog, the conditions for pgdat_free_space_enough() are quickly met, and triggers promotion. However, these migrated pages are only counted for in PGPROMOTE_SUCCESS, not in PGPROMOTE_CANDIDATE. To solve these confusing statistics, introduce PGPROMOTE_CANDIDATE_NRL to count the missed promotion pages. And also, not counting these pages into PGPROMOTE_CANDIDATE is to avoid changing the existing algorithm or performance of the promotion rate limit. Link: https://lkml.kernel.org/r/20250729035101.1601407-1-ruansy.fnst@fujitsu.com Co-developed-by: Li Zhijian <lizhijian(a)fujitsu.com> Signed-off-by: Ruan Shiyang <ruansy.fnst(a)fujitsu.com> Reported-by: Yasunori Gotou (Fujitsu) <y-goto(a)fujitsu.com> Suggested-by: Huang Ying <ying.huang(a)linux.alibaba.com> Acked-by: Vlastimil Babka <vbabka(a)suse.cz> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Juri Lelli <juri.lelli(a)redhat.com> Cc: Vincent Guittot <vincent.guittot(a)linaro.org> Cc: Dietmar Eggemann <dietmar.eggemann(a)arm.com> Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Ben Segall <bsegall(a)google.com> Cc: Mel Gorman <mgorman(a)suse.de> Cc: Valentin Schneider <vschneid(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- Changes since v1: 1. change Li Zhijian from 'Signed-off-by' to 'Co-developed-by' per Vlastimil. 2. add Acked-by: Vlastimil Babka <vbabka(a)suse.cz> --- include/linux/mmzone.h | 16 +++++++++++++++- kernel/sched/fair.c | 5 +++-- mm/vmstat.c | 1 + 3 files changed, 19 insertions(+), 3 deletions(-) diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h index 0c5da9141983..9d3ea9085556 100644 --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -234,7 +234,21 @@ enum node_stat_item { #endif #ifdef CONFIG_NUMA_BALANCING PGPROMOTE_SUCCESS, /* promote successfully */ - PGPROMOTE_CANDIDATE, /* candidate pages to promote */ + /** + * Candidate pages for promotion based on hint fault latency. This + * counter is used to control the promotion rate and adjust the hot + * threshold. + */ + PGPROMOTE_CANDIDATE, + /** + * Not rate-limited (NRL) candidate pages for those can be promoted + * without considering hot threshold because of enough free pages in + * fast-tier node. These promotions bypass the regular hotness checks + * and do NOT influence the promotion rate-limiter or + * threshold-adjustment logic. + * This is for statistics/monitoring purposes. + */ + PGPROMOTE_CANDIDATE_NRL, #endif /* PGDEMOTE_*: pages demoted */ PGDEMOTE_KSWAPD, diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index b173a059315c..82c8d804c54c 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -1923,11 +1923,13 @@ bool should_numa_migrate_memory(struct task_struct *p, struct folio *folio, struct pglist_data *pgdat; unsigned long rate_limit; unsigned int latency, th, def_th; + long nr = folio_nr_pages(folio); pgdat = NODE_DATA(dst_nid); if (pgdat_free_space_enough(pgdat)) { /* workload changed, reset hot threshold */ pgdat->nbp_threshold = 0; + mod_node_page_state(pgdat, PGPROMOTE_CANDIDATE_NRL, nr); return true; } @@ -1941,8 +1943,7 @@ bool should_numa_migrate_memory(struct task_struct *p, struct folio *folio, if (latency >= th) return false; - return !numa_promotion_rate_limit(pgdat, rate_limit, - folio_nr_pages(folio)); + return !numa_promotion_rate_limit(pgdat, rate_limit, nr); } this_cpupid = cpu_pid_to_cpupid(dst_cpu, current->pid); diff --git a/mm/vmstat.c b/mm/vmstat.c index 71cd1ceba191..e74f0b2a1021 100644 --- a/mm/vmstat.c +++ b/mm/vmstat.c @@ -1280,6 +1280,7 @@ const char * const vmstat_text[] = { #ifdef CONFIG_NUMA_BALANCING [I(PGPROMOTE_SUCCESS)] = "pgpromote_success", [I(PGPROMOTE_CANDIDATE)] = "pgpromote_candidate", + [I(PGPROMOTE_CANDIDATE_NRL)] = "pgpromote_candidate_nrl", #endif [I(PGDEMOTE_KSWAPD)] = "pgdemote_kswapd", [I(PGDEMOTE_DIRECT)] = "pgdemote_direct", -- 2.43.0

2 months

2
1
0 0

[PATCH] iommu/intel: Fix __domain_mapping()'s usage of switch_to_super_page()

by Eugene Koira

switch_to_super_page() assumes the memory range it's working on is aligned to the target large page level. Unfortunately, __domain_mapping() doesn't take this into account when using it, and will pass unaligned ranges ultimately freeing a PTE range larger than expected. Take for example a mapping with the following iov_pfn range [0x3fe400, 0x4c0600], which should be backed by the following mappings: iov_pfn [0x3fe400, 0x3fffff] covered by 2MiB pages iov_pfn [0x400000, 0x4bffff] covered by 1GiB pages iov_pfn [0x4c0000, 0x4c05ff] covered by 2MiB pages Under this circumstance, __domain_mapping() will pass [0x400000, 0x4c05ff] to switch_to_super_page() at a 1 GiB granularity, which will in turn free PTEs all the way to iov_pfn 0x4fffff. Mitigate this by rounding down the iov_pfn range passed to switch_to_super_page() in __domain_mapping() to the target large page level. Additionally add range alignment checks to switch_to_super_page. Fixes: 9906b9352a35 ("iommu/vt-d: Avoid duplicate removing in __domain_mapping()") Signed-off-by: Eugene Koira <eugkoira(a)amazon.com> Cc: stable(a)vger.kernel.org --- drivers/iommu/intel/iommu.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 9c3ab9d9f69a..dff2d895b8ab 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -1575,6 +1575,10 @@ static void switch_to_super_page(struct dmar_domain *domain, unsigned long lvl_pages = lvl_to_nr_pages(level); struct dma_pte *pte = NULL; + if (WARN_ON(!IS_ALIGNED(start_pfn, lvl_pages) || + !IS_ALIGNED(end_pfn + 1, lvl_pages))) + return; + while (start_pfn <= end_pfn) { if (!pte) pte = pfn_to_dma_pte(domain, start_pfn, &level, @@ -1650,7 +1654,8 @@ __domain_mapping(struct dmar_domain *domain, unsigned long iov_pfn, unsigned long pages_to_remove; pteval |= DMA_PTE_LARGE_PAGE; - pages_to_remove = min_t(unsigned long, nr_pages, + pages_to_remove = min_t(unsigned long, + round_down(nr_pages, lvl_pages), nr_pte_to_next_page(pte) * lvl_pages); end_pfn = iov_pfn + pages_to_remove - 1; switch_to_super_page(domain, iov_pfn, end_pfn, largepage_lvl); -- 2.47.3 Amazon Development Center (Netherlands) B.V., Johanna Westerdijkplein 1, NL-2521 EN The Hague, Registration No. Chamber of Commerce 56869649, VAT: NL 852339859B01

2 months

4
5
0 0

[PATCH] coresight: trbe: Fix incorrect error check for devm_kzalloc

by Miaoqian Lin

Fix incorrect use of IS_ERR() to check devm_kzalloc() return value. devm_kzalloc() returns NULL on failure, not an error pointer. This issue was introduced by commit 4277f035d227 ("coresight: trbe: Add a representative coresight_platform_data for TRBE") which replaced the original function but didn't update the error check. Fixes: 4277f035d227 ("coresight: trbe: Add a representative coresight_platform_data for TRBE") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/hwtracing/coresight/coresight-trbe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c index 8267dd1a2130..caf873adfc3a 100644 --- a/drivers/hwtracing/coresight/coresight-trbe.c +++ b/drivers/hwtracing/coresight/coresight-trbe.c @@ -1279,7 +1279,7 @@ static void arm_trbe_register_coresight_cpu(struct trbe_drvdata *drvdata, int cp * into the device for that purpose. */ desc.pdata = devm_kzalloc(dev, sizeof(*desc.pdata), GFP_KERNEL); - if (IS_ERR(desc.pdata)) + if (!desc.pdata) goto cpu_clear; desc.type = CORESIGHT_DEV_TYPE_SINK; -- 2.35.1

2 months

2
1
0 0

+ mm-fix-folio_expected_ref_count-when-pg_private_2.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: mm: fix folio_expected_ref_count() when PG_private_2 has been added to the -mm mm-new branch. Its filename is mm-fix-folio_expected_ref_count-when-pg_private_2.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Hugh Dickins <hughd(a)google.com> Subject: mm: fix folio_expected_ref_count() when PG_private_2 Date: Sun, 31 Aug 2025 02:01:16 -0700 (PDT) 6.16's folio_expected_ref_count() is forgetting the PG_private_2 flag, which (like PG_private, but not in addition to PG_private) counts for 1 more reference: it needs to be using folio_has_private() in place of folio_test_private(). But this went wrong earlier: folio_expected_ref_count() was based on (and replaced) mm/migrate.c's folio_expected_refs(), which has been using folio_test_private() since 6.0 converted to folios(): before that, expected_page_refs() was correctly using page_has_private(). Just a few filesystems are still using PG_private_2 a.k.a. PG_fscache. Potentially, this fix re-enables page migration on their folios; but it would not be surprising to learn that in practice those folios are not migratable for other reasons. Link: https://lkml.kernel.org/r/f91ee36e-a8cb-e3a4-c23b-524ff3848da7@google.com Fixes: 86ebd50224c0 ("mm: add folio_expected_ref_count() for reference count calculation") Fixes: 108ca8358139 ("mm/migrate: Convert expected_page_refs() to folio_expected_refs()") Signed-off-by: Hugh Dickins <hughd(a)google.com> Cc: "Aneesh Kumar K.V" <aneesh.kumar(a)kernel.org> Cc: Axel Rasmussen <axelrasmussen(a)google.com> Cc: Chris Li <chrisl(a)kernel.org> Cc: Christoph Hellwig <hch(a)infradead.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: John Hubbard <jhubbard(a)nvidia.com> Cc: Keir Fraser <keirf(a)google.com> Cc: Konstantin Khlebnikov <koct9i(a)gmail.com> Cc: Li Zhe <lizhe.67(a)bytedance.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Peter Xu <peterx(a)redhat.com> Cc: Shivank Garg <shivankg(a)amd.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Wei Xu <weixugc(a)google.com> Cc: Will Deacon <will(a)kernel.org> Cc: yangge <yangge1116(a)126.com> Cc: Yuanchu Xie <yuanchu(a)google.com> Cc: Yu Zhao <yuzhao(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/mm.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/include/linux/mm.h~mm-fix-folio_expected_ref_count-when-pg_private_2 +++ a/include/linux/mm.h @@ -2234,8 +2234,8 @@ static inline int folio_expected_ref_cou } else { /* One reference per page from the pagecache. */ ref_count += !!folio->mapping << order; - /* One reference from PG_private. */ - ref_count += folio_test_private(folio); + /* One reference from PG_private or PG_private_2. */ + ref_count += folio_has_private(folio); } /* One reference per page table mapping. */ _ Patches currently in -mm which might be from hughd(a)google.com are mm-fix-folio_expected_ref_count-when-pg_private_2.patch mm-gup-check-ref_count-instead-of-lru-before-migration.patch mm-gup-local-lru_add_drain-to-avoid-lru_add_drain_all.patch mm-revert-mm-gup-clear-the-lru-flag-of-a-page-before-adding-to-lru-batch.patch mm-revert-mm-vmscanc-fix-oom-on-swap-stress-test.patch mm-folio_may_be_cached-unless-folio_test_large.patch mm-lru_add_drain_all-do-local-lru_add_drain-first.patch

2 months

2
1
0 0

PCI: dwc: Ensure that dw_pcie_wait_for_link() waits 100 ms after link up

by Marek Vasut

Please backport the following commit into Linux v5.4 and newer stable releases: 80dc18a0cba8dea42614f021b20a04354b213d86 The backport will likely depend on macro rename commit: 817f989700fddefa56e5e443e7d138018ca6709d This part of commit description clarifies why this is a fix: " As per PCIe r6.0, sec 6.6.1, a Downstream Port that supports Link speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms after Link training completes before sending a Configuration Request. " In practice, this makes detection of PCIe Gen3 and Gen4 SSDs reliable on Renesas R-Car V4H SoC. Without this commit, the SSDs sporadically do not get detected, or sometimes they link up in Gen1 mode. This fixes commit 886bc5ceb5cc ("PCI: designware: Add generic dw_pcie_wait_for_link()") which is in v4.5-rc1-4-g886bc5ceb5cc3 , so I think this fix should be backported to all currently maintained stable releases, i.e. v5.4+ . Thank you -- Best regards, Marek Vasut

2 months

2
2
0 0

+ mm-folio_may_be_cached-unless-folio_test_large.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: mm: folio_may_be_cached() unless folio_test_large() has been added to the -mm mm-new branch. Its filename is mm-folio_may_be_cached-unless-folio_test_large.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Hugh Dickins <hughd(a)google.com> Subject: mm: folio_may_be_cached() unless folio_test_large() Date: Sun, 31 Aug 2025 02:16:25 -0700 (PDT) mm/swap.c and mm/mlock.c agree to drain any per-CPU batch as soon as a large folio is added: so collect_longterm_unpinnable_folios() just wastes effort when calling lru_add_drain_all() on a large folio. But although there is good reason not to batch up PMD-sized folios, we might well benefit from batching a small number of low-order mTHPs (though unclear how that "small number" limitation will be implemented). So ask if folio_may_be_cached() rather than !folio_test_large(), to insulate those particular checks from future change. Name preferred to "folio_is_batchable" because large folios can well be put on a batch: it's just the per-CPU LRU caches, drained much later, which need care. Marked for stable, to counter the increase in lru_add_drain_all()s from "mm/gup: check ref_count instead of lru before migration". Link: https://lkml.kernel.org/r/861c061c-51cd-b940-49df-9f55e1fee2c8@google.com Signed-off-by: Hugh Dickins <hughd(a)google.com> Suggested-by: David Hildenbrand <david(a)redhat.com> Cc: <stable(a)vger.kernel.org> Cc: "Aneesh Kumar K.V" <aneesh.kumar(a)kernel.org> Cc: Axel Rasmussen <axelrasmussen(a)google.com> Cc: Chris Li <chrisl(a)kernel.org> Cc: Christoph Hellwig <hch(a)infradead.org> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: John Hubbard <jhubbard(a)nvidia.com> Cc: Keir Fraser <keirf(a)google.com> Cc: Konstantin Khlebnikov <koct9i(a)gmail.com> Cc: Li Zhe <lizhe.67(a)bytedance.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Peter Xu <peterx(a)redhat.com> Cc: Shivank Garg <shivankg(a)amd.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Wei Xu <weixugc(a)google.com> Cc: Will Deacon <will(a)kernel.org> Cc: yangge <yangge1116(a)126.com> Cc: Yuanchu Xie <yuanchu(a)google.com> Cc: Yu Zhao <yuzhao(a)google.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/swap.h | 10 ++++++++++ mm/gup.c | 5 +++-- mm/mlock.c | 6 +++--- mm/swap.c | 2 +- 4 files changed, 17 insertions(+), 6 deletions(-) --- a/include/linux/swap.h~mm-folio_may_be_cached-unless-folio_test_large +++ a/include/linux/swap.h @@ -381,6 +381,16 @@ void folio_add_lru_vma(struct folio *, s void mark_page_accessed(struct page *); void folio_mark_accessed(struct folio *); +static inline bool folio_may_be_cached(struct folio *folio) +{ + /* + * Holding PMD-sized folios in per-CPU LRU cache unbalances accounting. + * Holding small numbers of low-order mTHP folios in per-CPU LRU cache + * will be sensible, but nobody has implemented and tested that yet. + */ + return !folio_test_large(folio); +} + extern atomic_t lru_disable_count; static inline bool lru_cache_disabled(void) --- a/mm/gup.c~mm-folio_may_be_cached-unless-folio_test_large +++ a/mm/gup.c @@ -2309,8 +2309,9 @@ static unsigned long collect_longterm_un continue; } - if (drain_allow && folio_ref_count(folio) != - folio_expected_ref_count(folio) + 1) { + if (drain_allow && folio_may_be_cached(folio) && + folio_ref_count(folio) != + folio_expected_ref_count(folio) + 1) { lru_add_drain_all(); drain_allow = false; } --- a/mm/mlock.c~mm-folio_may_be_cached-unless-folio_test_large +++ a/mm/mlock.c @@ -255,7 +255,7 @@ void mlock_folio(struct folio *folio) folio_get(folio); if (!folio_batch_add(fbatch, mlock_lru(folio)) || - folio_test_large(folio) || lru_cache_disabled()) + !folio_may_be_cached(folio) || lru_cache_disabled()) mlock_folio_batch(fbatch); local_unlock(&mlock_fbatch.lock); } @@ -278,7 +278,7 @@ void mlock_new_folio(struct folio *folio folio_get(folio); if (!folio_batch_add(fbatch, mlock_new(folio)) || - folio_test_large(folio) || lru_cache_disabled()) + !folio_may_be_cached(folio) || lru_cache_disabled()) mlock_folio_batch(fbatch); local_unlock(&mlock_fbatch.lock); } @@ -299,7 +299,7 @@ void munlock_folio(struct folio *folio) */ folio_get(folio); if (!folio_batch_add(fbatch, folio) || - folio_test_large(folio) || lru_cache_disabled()) + !folio_may_be_cached(folio) || lru_cache_disabled()) mlock_folio_batch(fbatch); local_unlock(&mlock_fbatch.lock); } --- a/mm/swap.c~mm-folio_may_be_cached-unless-folio_test_large +++ a/mm/swap.c @@ -192,7 +192,7 @@ static void __folio_batch_add_and_move(s local_lock(&cpu_fbatches.lock); if (!folio_batch_add(this_cpu_ptr(fbatch), folio) || - folio_test_large(folio) || lru_cache_disabled()) + !folio_may_be_cached(folio) || lru_cache_disabled()) folio_batch_move_lru(this_cpu_ptr(fbatch), move_fn); if (disable_irq) _ Patches currently in -mm which might be from hughd(a)google.com are mm-fix-folio_expected_ref_count-when-pg_private_2.patch mm-gup-check-ref_count-instead-of-lru-before-migration.patch mm-gup-local-lru_add_drain-to-avoid-lru_add_drain_all.patch mm-revert-mm-gup-clear-the-lru-flag-of-a-page-before-adding-to-lru-batch.patch mm-revert-mm-vmscanc-fix-oom-on-swap-stress-test.patch mm-folio_may_be_cached-unless-folio_test_large.patch mm-lru_add_drain_all-do-local-lru_add_drain-first.patch

2 months

1
0
0 0

+ mm-revert-mm-vmscanc-fix-oom-on-swap-stress-test.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: mm: Revert "mm: vmscan.c: fix OOM on swap stress test" has been added to the -mm mm-new branch. Its filename is mm-revert-mm-vmscanc-fix-oom-on-swap-stress-test.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Hugh Dickins <hughd(a)google.com> Subject: mm: Revert "mm: vmscan.c: fix OOM on swap stress test" Date: Sun, 31 Aug 2025 02:13:55 -0700 (PDT) This reverts commit 0885ef4705607936fc36a38fd74356e1c465b023: that was a fix to the reverted 33dfe9204f29b415bbc0abb1a50642d1ba94f5e9. Link: https://lkml.kernel.org/r/bd440614-3d2c-31d6-1b8f-9635c69cef7c@google.com Fixes: 0885ef470560 ("mm: vmscan.c: fix OOM on swap stress test") Signed-off-by: Hugh Dickins <hughd(a)google.com> Cc: <stable(a)vger.kernel.org> Cc: "Aneesh Kumar K.V" <aneesh.kumar(a)kernel.org> Cc: Axel Rasmussen <axelrasmussen(a)google.com> Cc: Chris Li <chrisl(a)kernel.org> Cc: Christoph Hellwig <hch(a)infradead.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: John Hubbard <jhubbard(a)nvidia.com> Cc: Keir Fraser <keirf(a)google.com> Cc: Konstantin Khlebnikov <koct9i(a)gmail.com> Cc: Li Zhe <lizhe.67(a)bytedance.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Peter Xu <peterx(a)redhat.com> Cc: Shivank Garg <shivankg(a)amd.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Wei Xu <weixugc(a)google.com> Cc: Will Deacon <will(a)kernel.org> Cc: yangge <yangge1116(a)126.com> Cc: Yuanchu Xie <yuanchu(a)google.com> Cc: Yu Zhao <yuzhao(a)google.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/vmscan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/vmscan.c~mm-revert-mm-vmscanc-fix-oom-on-swap-stress-test +++ a/mm/vmscan.c @@ -4500,7 +4500,7 @@ static bool sort_folio(struct lruvec *lr } /* ineligible */ - if (!folio_test_lru(folio) || zone > sc->reclaim_idx) { + if (zone > sc->reclaim_idx) { gen = folio_inc_gen(lruvec, folio, false); list_move_tail(&folio->lru, &lrugen->folios[gen][type][zone]); return true; _ Patches currently in -mm which might be from hughd(a)google.com are mm-fix-folio_expected_ref_count-when-pg_private_2.patch mm-gup-check-ref_count-instead-of-lru-before-migration.patch mm-gup-local-lru_add_drain-to-avoid-lru_add_drain_all.patch mm-revert-mm-gup-clear-the-lru-flag-of-a-page-before-adding-to-lru-batch.patch mm-revert-mm-vmscanc-fix-oom-on-swap-stress-test.patch mm-folio_may_be_cached-unless-folio_test_large.patch mm-lru_add_drain_all-do-local-lru_add_drain-first.patch

2 months

1
0
0 0

+ mm-revert-mm-gup-clear-the-lru-flag-of-a-page-before-adding-to-lru-batch.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: mm: Revert "mm/gup: clear the LRU flag of a page before adding to LRU batch" has been added to the -mm mm-new branch. Its filename is mm-revert-mm-gup-clear-the-lru-flag-of-a-page-before-adding-to-lru-batch.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Hugh Dickins <hughd(a)google.com> Subject: mm: Revert "mm/gup: clear the LRU flag of a page before adding to LRU batch" Date: Sun, 31 Aug 2025 02:11:33 -0700 (PDT) This reverts commit 33dfe9204f29b415bbc0abb1a50642d1ba94f5e9: now that collect_longterm_unpinnable_folios() is checking ref_count instead of lru, and mlock/munlock do not participate in the revised LRU flag clearing, those changes are misleading, and enlarge the window during which mlock/munlock may miss an mlock_count update. It is possible (I'd hesitate to claim probable) that the greater likelihood of missed mlock_count updates would explain the "Realtime threads delayed due to kcompactd0" observed on 6.12 in the Link below. If that is the case, this reversion will help; but a complete solution needs also a further patch, beyond the scope of this series. Included some 80-column cleanup around folio_batch_add_and_move(). The role of folio_test_clear_lru() (before taking per-memcg lru_lock) is questionable since 6.13 removed mem_cgroup_move_account() etc; but perhaps there are still some races which need it - not examined here. Link: https://lore.kernel.org/linux-mm/DU0PR01MB10385345F7153F334100981888259A@DU… Link: https://lkml.kernel.org/r/0215a42b-99cd-612a-95f7-56f8251d99ef@google.com Fixes: 33dfe9204f29 ("mm/gup: clear the LRU flag of a page before adding to LRU batch") Signed-off-by: Hugh Dickins <hughd(a)google.com> Cc: <stable(a)vger.kernel.org> Cc: "Aneesh Kumar K.V" <aneesh.kumar(a)kernel.org> Cc: Axel Rasmussen <axelrasmussen(a)google.com> Cc: Chris Li <chrisl(a)kernel.org> Cc: Christoph Hellwig <hch(a)infradead.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: John Hubbard <jhubbard(a)nvidia.com> Cc: Keir Fraser <keirf(a)google.com> Cc: Konstantin Khlebnikov <koct9i(a)gmail.com> Cc: Li Zhe <lizhe.67(a)bytedance.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Peter Xu <peterx(a)redhat.com> Cc: Shivank Garg <shivankg(a)amd.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Wei Xu <weixugc(a)google.com> Cc: Will Deacon <will(a)kernel.org> Cc: yangge <yangge1116(a)126.com> Cc: Yuanchu Xie <yuanchu(a)google.com> Cc: Yu Zhao <yuzhao(a)google.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/swap.c | 50 ++++++++++++++++++++++++++------------------------ 1 file changed, 26 insertions(+), 24 deletions(-) --- a/mm/swap.c~mm-revert-mm-gup-clear-the-lru-flag-of-a-page-before-adding-to-lru-batch +++ a/mm/swap.c @@ -164,6 +164,10 @@ static void folio_batch_move_lru(struct for (i = 0; i < folio_batch_count(fbatch); i++) { struct folio *folio = fbatch->folios[i]; + /* block memcg migration while the folio moves between lru */ + if (move_fn != lru_add && !folio_test_clear_lru(folio)) + continue; + folio_lruvec_relock_irqsave(folio, &lruvec, &flags); move_fn(lruvec, folio); @@ -176,14 +180,10 @@ static void folio_batch_move_lru(struct } static void __folio_batch_add_and_move(struct folio_batch __percpu *fbatch, - struct folio *folio, move_fn_t move_fn, - bool on_lru, bool disable_irq) + struct folio *folio, move_fn_t move_fn, bool disable_irq) { unsigned long flags; - if (on_lru && !folio_test_clear_lru(folio)) - return; - folio_get(folio); if (disable_irq) @@ -191,8 +191,8 @@ static void __folio_batch_add_and_move(s else local_lock(&cpu_fbatches.lock); - if (!folio_batch_add(this_cpu_ptr(fbatch), folio) || folio_test_large(folio) || - lru_cache_disabled()) + if (!folio_batch_add(this_cpu_ptr(fbatch), folio) || + folio_test_large(folio) || lru_cache_disabled()) folio_batch_move_lru(this_cpu_ptr(fbatch), move_fn); if (disable_irq) @@ -201,13 +201,13 @@ static void __folio_batch_add_and_move(s local_unlock(&cpu_fbatches.lock); } -#define folio_batch_add_and_move(folio, op, on_lru) \ - __folio_batch_add_and_move( \ - &cpu_fbatches.op, \ - folio, \ - op, \ - on_lru, \ - offsetof(struct cpu_fbatches, op) >= offsetof(struct cpu_fbatches, lock_irq) \ +#define folio_batch_add_and_move(folio, op) \ + __folio_batch_add_and_move( \ + &cpu_fbatches.op, \ + folio, \ + op, \ + offsetof(struct cpu_fbatches, op) >= \ + offsetof(struct cpu_fbatches, lock_irq) \ ) static void lru_move_tail(struct lruvec *lruvec, struct folio *folio) @@ -231,10 +231,10 @@ static void lru_move_tail(struct lruvec void folio_rotate_reclaimable(struct folio *folio) { if (folio_test_locked(folio) || folio_test_dirty(folio) || - folio_test_unevictable(folio)) + folio_test_unevictable(folio) || !folio_test_lru(folio)) return; - folio_batch_add_and_move(folio, lru_move_tail, true); + folio_batch_add_and_move(folio, lru_move_tail); } void lru_note_cost_unlock_irq(struct lruvec *lruvec, bool file, @@ -328,10 +328,11 @@ static void folio_activate_drain(int cpu void folio_activate(struct folio *folio) { - if (folio_test_active(folio) || folio_test_unevictable(folio)) + if (folio_test_active(folio) || folio_test_unevictable(folio) || + !folio_test_lru(folio)) return; - folio_batch_add_and_move(folio, lru_activate, true); + folio_batch_add_and_move(folio, lru_activate); } #else @@ -507,7 +508,7 @@ void folio_add_lru(struct folio *folio) lru_gen_in_fault() && !(current->flags & PF_MEMALLOC)) folio_set_active(folio); - folio_batch_add_and_move(folio, lru_add, false); + folio_batch_add_and_move(folio, lru_add); } EXPORT_SYMBOL(folio_add_lru); @@ -685,13 +686,13 @@ void lru_add_drain_cpu(int cpu) void deactivate_file_folio(struct folio *folio) { /* Deactivating an unevictable folio will not accelerate reclaim */ - if (folio_test_unevictable(folio)) + if (folio_test_unevictable(folio) || !folio_test_lru(folio)) return; if (lru_gen_enabled() && lru_gen_clear_refs(folio)) return; - folio_batch_add_and_move(folio, lru_deactivate_file, true); + folio_batch_add_and_move(folio, lru_deactivate_file); } /* @@ -704,13 +705,13 @@ void deactivate_file_folio(struct folio */ void folio_deactivate(struct folio *folio) { - if (folio_test_unevictable(folio)) + if (folio_test_unevictable(folio) || !folio_test_lru(folio)) return; if (lru_gen_enabled() ? lru_gen_clear_refs(folio) : !folio_test_active(folio)) return; - folio_batch_add_and_move(folio, lru_deactivate, true); + folio_batch_add_and_move(folio, lru_deactivate); } /** @@ -723,10 +724,11 @@ void folio_deactivate(struct folio *foli void folio_mark_lazyfree(struct folio *folio) { if (!folio_test_anon(folio) || !folio_test_swapbacked(folio) || + !folio_test_lru(folio) || folio_test_swapcache(folio) || folio_test_unevictable(folio)) return; - folio_batch_add_and_move(folio, lru_lazyfree, true); + folio_batch_add_and_move(folio, lru_lazyfree); } void lru_add_drain(void) _ Patches currently in -mm which might be from hughd(a)google.com are mm-fix-folio_expected_ref_count-when-pg_private_2.patch mm-gup-check-ref_count-instead-of-lru-before-migration.patch mm-gup-local-lru_add_drain-to-avoid-lru_add_drain_all.patch mm-revert-mm-gup-clear-the-lru-flag-of-a-page-before-adding-to-lru-batch.patch mm-revert-mm-vmscanc-fix-oom-on-swap-stress-test.patch mm-folio_may_be_cached-unless-folio_test_large.patch mm-lru_add_drain_all-do-local-lru_add_drain-first.patch

2 months

1
0
0 0

+ mm-gup-local-lru_add_drain-to-avoid-lru_add_drain_all.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: mm/gup: local lru_add_drain() to avoid lru_add_drain_all() has been added to the -mm mm-new branch. Its filename is mm-gup-local-lru_add_drain-to-avoid-lru_add_drain_all.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Hugh Dickins <hughd(a)google.com> Subject: mm/gup: local lru_add_drain() to avoid lru_add_drain_all() Date: Sun, 31 Aug 2025 02:08:26 -0700 (PDT) In many cases, if collect_longterm_unpinnable_folios() does need to drain the LRU cache to release a reference, the cache in question is on this same CPU, and much more efficiently drained by a preliminary local lru_add_drain(), than the later cross-CPU lru_add_drain_all(). Marked for stable, to counter the increase in lru_add_drain_all()s from "mm/gup: check ref_count instead of lru before migration". Note for clean backports: can take 6.16 commit a03db236aebf ("gup: optimize longterm pin_user_pages() for large folio") first. Link: https://lkml.kernel.org/r/165ccfdb-16b5-ac11-0d66-2984293590c8@google.com Signed-off-by: Hugh Dickins <hughd(a)google.com> Cc: <stable(a)vger.kernel.org> Cc: "Aneesh Kumar K.V" <aneesh.kumar(a)kernel.org> Cc: Axel Rasmussen <axelrasmussen(a)google.com> Cc: Chris Li <chrisl(a)kernel.org> Cc: Christoph Hellwig <hch(a)infradead.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: John Hubbard <jhubbard(a)nvidia.com> Cc: Keir Fraser <keirf(a)google.com> Cc: Konstantin Khlebnikov <koct9i(a)gmail.com> Cc: Li Zhe <lizhe.67(a)bytedance.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Peter Xu <peterx(a)redhat.com> Cc: Shivank Garg <shivankg(a)amd.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Wei Xu <weixugc(a)google.com> Cc: Will Deacon <will(a)kernel.org> Cc: yangge <yangge1116(a)126.com> Cc: Yuanchu Xie <yuanchu(a)google.com> Cc: Yu Zhao <yuzhao(a)google.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/gup.c | 2 ++ 1 file changed, 2 insertions(+) --- a/mm/gup.c~mm-gup-local-lru_add_drain-to-avoid-lru_add_drain_all +++ a/mm/gup.c @@ -2291,6 +2291,8 @@ static unsigned long collect_longterm_un struct folio *folio; long i = 0; + lru_add_drain(); + for (folio = pofs_get_folio(pofs, i); folio; folio = pofs_next_folio(folio, pofs, &i)) { _ Patches currently in -mm which might be from hughd(a)google.com are mm-fix-folio_expected_ref_count-when-pg_private_2.patch mm-gup-check-ref_count-instead-of-lru-before-migration.patch mm-gup-local-lru_add_drain-to-avoid-lru_add_drain_all.patch mm-revert-mm-gup-clear-the-lru-flag-of-a-page-before-adding-to-lru-batch.patch mm-revert-mm-vmscanc-fix-oom-on-swap-stress-test.patch mm-folio_may_be_cached-unless-folio_test_large.patch mm-lru_add_drain_all-do-local-lru_add_drain-first.patch

2 months

1
0
0 0

+ mm-gup-check-ref_count-instead-of-lru-before-migration.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: mm/gup: check ref_count instead of lru before migration has been added to the -mm mm-new branch. Its filename is mm-gup-check-ref_count-instead-of-lru-before-migration.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Hugh Dickins <hughd(a)google.com> Subject: mm/gup: check ref_count instead of lru before migration Date: Sun, 31 Aug 2025 02:05:56 -0700 (PDT) Will Deacon reports:- When taking a longterm GUP pin via pin_user_pages(), __gup_longterm_locked() tries to migrate target folios that should not be longterm pinned, for example because they reside in a CMA region or movable zone. This is done by first pinning all of the target folios anyway, collecting all of the longterm-unpinnable target folios into a list, dropping the pins that were just taken and finally handing the list off to migrate_pages() for the actual migration. It is critically important that no unexpected references are held on the folios being migrated, otherwise the migration will fail and pin_user_pages() will return -ENOMEM to its caller. Unfortunately, it is relatively easy to observe migration failures when running pKVM (which uses pin_user_pages() on crosvm's virtual address space to resolve stage-2 page faults from the guest) on a 6.15-based Pixel 6 device and this results in the VM terminating prematurely. In the failure case, 'crosvm' has called mlock(MLOCK_ONFAULT) on its mapping of guest memory prior to the pinning. Subsequently, when pin_user_pages() walks the page-table, the relevant 'pte' is not present and so the faulting logic allocates a new folio, mlocks it with mlock_folio() and maps it in the page-table. Since commit 2fbb0c10d1e8 ("mm/munlock: mlock_page() munlock_page() batch by pagevec"), mlock/munlock operations on a folio (formerly page), are deferred. For example, mlock_folio() takes an additional reference on the target folio before placing it into a per-cpu 'folio_batch' for later processing by mlock_folio_batch(), which drops the refcount once the operation is complete. Processing of the batches is coupled with the LRU batch logic and can be forcefully drained with lru_add_drain_all() but as long as a folio remains unprocessed on the batch, its refcount will be elevated. This deferred batching therefore interacts poorly with the pKVM pinning scenario as we can find ourselves in a situation where the migration code fails to migrate a folio due to the elevated refcount from the pending mlock operation. Hugh Dickins adds:- !folio_test_lru() has never been a very reliable way to tell if an lru_add_drain_all() is worth calling, to remove LRU cache references to make the folio migratable: the LRU flag may be set even while the folio is held with an extra reference in a per-CPU LRU cache. 5.18 commit 2fbb0c10d1e8 may have made it more unreliable. Then 6.11 commit 33dfe9204f29 ("mm/gup: clear the LRU flag of a page before adding to LRU batch") tried to make it reliable, by moving LRU flag clearing; but missed the mlock/munlock batches, so still unreliable as reported. And it turns out to be difficult to extend 33dfe9204f29's LRU flag clearing to the mlock/munlock batches: if they do benefit from batching, mlock/munlock cannot be so effective when easily suppressed while !LRU. Instead, switch to an expected ref_count check, which was more reliable all along: some more false positives (unhelpful drains) than before, and never a guarantee that the folio will prove migratable, but better. Note for stable backports: requires 6.16 commit 86ebd50224c0 ("mm: add folio_expected_ref_count() for reference count calculation") and 6.17 commit ("mm: fix folio_expected_ref_count() when PG_private_2"). Link: https://lkml.kernel.org/r/47c51c9a-140f-1ea1-b692-c4bae5d1fa58@google.com Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages allocated from CMA region") Signed-off-by: Hugh Dickins <hughd(a)google.com> Reported-by: Will Deacon <will(a)kernel.org> Link: https://lore.kernel.org/linux-mm/20250815101858.24352-1-will@kernel.org/ Cc: <stable(a)vger.kernel.org> Cc: "Aneesh Kumar K.V" <aneesh.kumar(a)kernel.org> Cc: Axel Rasmussen <axelrasmussen(a)google.com> Cc: Chris Li <chrisl(a)kernel.org> Cc: Christoph Hellwig <hch(a)infradead.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: John Hubbard <jhubbard(a)nvidia.com> Cc: Keir Fraser <keirf(a)google.com> Cc: Konstantin Khlebnikov <koct9i(a)gmail.com> Cc: Li Zhe <lizhe.67(a)bytedance.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Peter Xu <peterx(a)redhat.com> Cc: Shivank Garg <shivankg(a)amd.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Wei Xu <weixugc(a)google.com> Cc: yangge <yangge1116(a)126.com> Cc: Yuanchu Xie <yuanchu(a)google.com> Cc: Yu Zhao <yuzhao(a)google.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/gup.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/mm/gup.c~mm-gup-check-ref_count-instead-of-lru-before-migration +++ a/mm/gup.c @@ -2307,7 +2307,8 @@ static unsigned long collect_longterm_un continue; } - if (!folio_test_lru(folio) && drain_allow) { + if (drain_allow && folio_ref_count(folio) != + folio_expected_ref_count(folio) + 1) { lru_add_drain_all(); drain_allow = false; } _ Patches currently in -mm which might be from hughd(a)google.com are mm-fix-folio_expected_ref_count-when-pg_private_2.patch mm-gup-check-ref_count-instead-of-lru-before-migration.patch mm-gup-local-lru_add_drain-to-avoid-lru_add_drain_all.patch mm-revert-mm-gup-clear-the-lru-flag-of-a-page-before-adding-to-lru-batch.patch mm-revert-mm-vmscanc-fix-oom-on-swap-stress-test.patch mm-folio_may_be_cached-unless-folio_test_large.patch mm-lru_add_drain_all-do-local-lru_add_drain-first.patch

2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror