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

On Fri, Aug 28, 2026 at 05:18:05PM -0700, David Stevens wrote:

On Fri, Aug 28, 2026 at 5:04 AM Peter Zijlstra [off-list ref] wrote:

quoted

On Thu, Aug 27, 2026 at 04:29:44PM -0700, David Stevens wrote:

quoted

@@ -4320,8 +4319,18 @@ int try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
               * A similar smp_rmb() lives in __task_needs_rq_lock().
               */
              smp_rmb();
-             if (READ_ONCE(p->on_rq) && ttwu_runnable(p, wake_flags))
+             if (READ_ONCE(p->on_rq) && ttwu_runnable(p, wake_flags)) {
+                     trace_sched_waking(p);
+                     break;
+             }
+
+             if (!ensure_stack_is_present(p, &need_deferred_repopulate)) {
+                     WRITE_ONCE(p->__state, TASK_STACK_RECLAIM);
+                     do_deferred_repopulate_wake = need_deferred_repopulate;
                      break;
+             }
+
+             trace_sched_waking(p);

Absolutely not; ensure_stack_is_present() must not call
repopulate_stack() while holding ->pi_lock. Not happening.

The optimistic fast path for repopulate_stack() could be modified to
try pulling from a pre-allocated pool of zero'ed pages. That would
reduce the function to a couple of memcg_kmem_charge_page() calls and

Afaict memcg_kmem_charge_page() ends up in a local_lock, which is a
spinlock, so that cannot be.

Most, if not everything, in mm/ is build around being preemptible and
thus not suitable for use under raw_spinlock_t.

then vmap_pages_range() to repopulate the stack's page tables. That

vmap_page_range() can end up in the allocator, which I suppose is ruled
out by the vmap having been populated before, but it still has a
might_sleep() that will scream AFAICT.

wouldn't require touching any locks except a raw_spinlock protecting
the pre-allocated pool (or just make it per_cpu). In terms of cost,
this would involve a couple of atomic operations for the page pool
lock and the memcg charging plus non-atomic operations on 5-10 other
cache lines.

Is that within the scope of what can be done under the pi_lock? If
that's still not happening, I can see how things look if we always
defer wakeup to a workqueue.

As long as it really is all atomics it should be fine. If there is a
lock, it must be raw_spinlock_t, but ideally no new locks nested under
pi_lock.