Thread (49 messages) flat view 49 messages, 8 authors, 7d ago

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_KCORE
This 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help