Re: [RFC 06/10] Reclaim memory from blocked kernel stacks
From: David Stevens <hidden>
Date: 2026-08-28 20:50:31
Also in:
linux-mm, linux-rt-devel, lkml
On Fri, Aug 28, 2026 at 6:59 AM Peter Zijlstra [off-list ref] wrote:
On Fri, Aug 28, 2026 at 03:36:20PM +0200, Sebastian Andrzej Siewior wrote:quoted
On 2026-08-27 16:29:44 [-0700], David Stevens wrote:quoted
diff --git a/arch/Kconfig b/arch/Kconfig index fa7507ac8e13..adb4a5957996 100644 --- a/arch/Kconfig +++ b/arch/Kconfig@@ -1534,6 +1534,24 @@ config VMAP_STACK backing virtual mappings with real shadow memory, and KASAN_VMALLOC must be enabled. +config HAVE_ARCH_RECLAIMABLE_STACK + def_bool n + +config RECLAIMABLE_STACK + default !PREEMPT_RT && !PROC_KCOREThis shouldn't default like this for RT. It either is useable or it is not.quoted
+ bool "Allow stacks of some blocked threads to be reclaimed" + depends on VMAP_STACK && !STACK_GROWSUP + depends on HAVE_ARCH_RECLAIMABLE_STACK + depends on !DEBUG_STACK_USAGE + depends on !KASAN_VMALLOC # TODO: add support for this + depends on !DEBUG_KMEMLEAK # TODO: add support for this + help + Enable this to allow the unused portion of kernel stacks of most + blocked tasks to be reclaimed. + + The wakeup latency of tasks with reclaimed stacks may increase, + especially while the system is under memory pressure.It says *may* increase and on RT it _definitely_ will increase since there is a kworker involved not to mention the memory allocation itself. Anyway. This either needs to stay away from PREEMPT_RT or find a way to exclude at the very least mlock()ed tasks. Did lockdep see this?It should have. They're taking spinlock inside raw_spinlock and lockdep should very much warn about that by default.
It does trylocks on spinlocks and local locks, inside of alloc_pages_nolock_noprof(). Lockdep considers that safe. On PREEMPT_RT, it is necessary to skip the call to alloc_pages_nolock_noprof() from under pi_lock, since with that configuration spin_trylock can end up needing to take pi_lock. But at least on !PREEMPT_RT, there is no risk of deadlock. -David