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

Re: [RFC 00/10] Reclaimable kernel stacks

From: Peter Zijlstra <peterz@infradead.org>
Date: 2026-08-28 12:48:20
Also in: linux-mm, linux-rt-devel, lkml

On Thu, Aug 27, 2026 at 04:29:38PM -0700, David Stevens wrote:
On Android, system processes typically have 2000-3000 threads. App
processes add 1000s more threads on top of this.
WTF ?!? Why does that all spawn *that* many threads? Perhaps work on
reducing that some?
Tracking blocked state and when it is safe to reclaim a stack is done
via a series of hooks in the scheduler. The actual reclaim of stacks is
done asynchronously in a shrinker.

Once a task's stack has been reclaimed, it cannot be rescheduled until
its stack is repopulated. Although there can be a repopulation fast path
within the scheduler, reliably allocating memory to repopulate the stack
requires a fallback path that defers the repopulation and wakeup to a
workqueue context that can use GFP_KERNEL.
I am really confused. On the one hand you have John working on proxy
execution, with the aim on reducing latencies, and then here you are,
posting something that will introduce basically unbound latencies.


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help