[RFC 06/10] Reclaim memory from blocked kernel stacks

[Will Deacon]

On Fri, Aug 28, 2026 at 05:10:18PM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-08-28 15:59:47 [+0200], Peter Zijlstra wrote:
> > > > +
> > > > +	  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.
> 
> Yes. My point was that this was hidden from lockdep.
> 
> > > If I understood the whole exercise correct then you have a kernel stack
> > > of two pages and in best case you can unmap and release the second page
> > > while the task is napping.
> > 
> > THREAD_SIZE_ORDER	2
> > THREAD_SIZE		(PAGE_SIZE << THREAD_SIZE_ORDER)
> > 
> > that makes for 4 pages.
> 
> Oh. I wasn't aware that we have 16kib stacks these days. But looking
> at it we have it now for over 10 years… Judging from 6538b8ea886e4
> ("x86_64: expand kernel stack to 16K") it might be temporary and things
> are better now? Arm64 has a different story according to 845ad05ec31e0
> ("arm64: Change kernel stack size to 16K"). Risc-V also mentions "for
> now" in 0cac21b02ba5f ("riscv: use 16KB kernel stack on 64-bit").

FWIW, I'm hoping to make the arm64 stack size configurable on the kernel
cmdline with a view to changing the default back to 8k (assuming a 4k
page size). With 8k, we currently see some overflows in direct reclaim
(mirrored by a later stacktrace in this thread), but Suren has been
looking at ways to improve that (e.g. by moving it into a separate
kthread) which look promising.

Will