Re: [PATCH] mm/madvise: add cond_resched() in THP branch of madvise_cold_or_pageout_pte_range()

[David Hildenbrand (Arm)]

On 10/10/26 04:40, albin_yang@xxxxxxx wrote:
> From: Wei Yang <albinwyang@xxxxxxxxxxx>
> 
> During stress testing with stress-ng on a 256-CPU system, a softlockup
> was observed when madvise(MADV_COLD) was called on a 31GB memory region
> backed by transparent hugepages. The region contains 15935 THP PMD
> entries, and the softlockup was triggered after 14485 of them had been
> processed.
> 
> The THP branch of madvise_cold_or_pageout_pte_range() has no scheduling
> point. walk_pmd_range() invokes it once per 2MB PMD entry with no
> cond_resched() anywhere in the loop. Each iteration calls
> pmdp_invalidate() which issues a synchronous TLB shootdown (dsb ish)
> waiting for all CPUs to acknowledge. This operation can be
> time-consuming under heavy system load, causing the accumulated time
> across all PMD entries to exceed the softlockup threshold (20s) and
> panic when softlockup_panic=1. On a CONFIG_PREEMPT_NONE=y kernel, there
> is no other opportunity to reschedule during this entire traversal.
> 
> The regular PTE path already has an unconditional cond_resched() at the
> function tail (introduced by commit 9c276cc65a58 ("mm: introduce
> MADV_COLD") and commit 1a4e58cce84e ("mm: introduce MADV_PAGEOUT") when
> MADV_COLD and MADV_PAGEOUT were first introduced) and a conditional one
> inside the loop (commit b2f557a21bc8 ("mm/madvise: add cond_resched()
> in madvise_cold_or_pageout_pte_range()")). The THP branch never
> received equivalent treatment.

That's quite a text to say "Do it just like the PTE case" ;)

Acked-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>

-- 
Cheers,

David