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

[Peter Zijlstra]

On Fri, Aug 28, 2026 at 05:18:05PM -0700, David Stevens wrote:
> On Fri, Aug 28, 2026 at 5:04 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> >
> > On Thu, Aug 27, 2026 at 04:29:44PM -0700, David Stevens wrote:
> > > @@ -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.