Re: [PATCH v2 00/13] Dynamic Kernel Stacks

[David Laight <david.laight.linux@gmail.com>]

On Tue, 23 Jun 2026 09:50:00 +0200
"David Hildenbrand (Arm)" <david@kernel.org> wrote:

...
> There was some (hallway?) talk at LSF/MM about possibly removing direct reclaim,
> similar to how other operating systems handle it. Now, I don't know how feasible
> it is (I guess devil is in the detail ;) ), or any details how that would work,
> but direct reclaim was repeatedly called out as one of the main reasons we can
> get huge stacks.
> 
> So I guess direct reclaim (incl. compaction) is one of the main problematic
> pieces. Are we aware of other scenarios where we (easily) trigger consumption of
> larger stacks?

I suspect some printk in error paths could get problematic.
Especially if they involve direct writes to a non-trivial console
(does that happen any more??).
How much stack does dump_stack() need?

> Wild idea: as a first step to test the waters, use smaller stacks on selected
> kernel threads and disallow direct reclaim/compaction if the stack for the
> thread is small?

Or if there isn't much stack space left?

Isn't reclaim one of the places that is actually likely to exceed the stack
limit because it is unusual and won't be exercised at most of the kmalloc()
call sites?
One you get to the slow bits (especially ones that do IO) it is unlikely
that a context-switch to a special worker thread will make much difference.
(You might need to boost the thread priority based on the priority of the
waiting process.)

	David