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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 6/23/26 11:10, David Laight wrote:
> 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??).

Good question!

> 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.)

I think that was exactly the idea of removing direct reclaim: instead of doing
reclaim yourself, you trigger another (reclaim) thread (like kswapd) and wait
for it to finish.

-- 
Cheers,

David