Re: [PATCH v23 5/9] sched: Add logic to zap balance callbacks if we pick again

[John Stultz]

On Thu, Oct 30, 2025 at 1:08 AM K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:
> On 10/30/2025 5:48 AM, John Stultz wrote:
> > +#ifdef CONFIG_SCHED_PROXY_EXEC
> > +/*
> > + * Only called from __schedule context
> > + *
> > + * There are some cases where we are going to re-do the action
> > + * that added the balance callbacks. We may not be in a state
> > + * where we can run them, so just zap them so they can be
> > + * properly re-added on the next time around. This is similar
> > + * handling to running the callbacks, except we just don't call
> > + * them.
> > + */
> > +static void zap_balance_callbacks(struct rq *rq)
> > +{
> > +     struct balance_callback *next, *head;
> > +     bool found = false;
> > +
> > +     lockdep_assert_rq_held(rq);
> > +
> > +     head = rq->balance_callback;
> > +     while (head) {
> > +             if (head == &balance_push_callback)
> > +                     found = true;
> > +             next = head->next;
> > +             head->next = NULL;
> > +             head = next;
> > +     }
> > +     rq->balance_callback = found ? &balance_push_callback : NULL;
> > +}
>
> There is nothing proxy-exec specific in this function. Do we need to
> keep it behind CONFIG_SCHED_PROXY_EXEC?
>
> I believe compiler will optimize out the dead code and having
> zap_balance_callbacks() unconditionally shouldn't have make any
> difference to the size of generated binary for
> !CONFIG_SCHED_PROXY_EXEC case.

Good point. I'll drop that.


> Apart from that nit. feel free to include:
>
> Reviewed-by: K Prateek Nayak <kprateek.nayak@xxxxxxx>

Thank you!

> > @@ -6901,10 +6933,15 @@ static void __sched notrace __schedule(int sched_mode)
> >       rq_set_donor(rq, next);
> >       if (unlikely(task_is_blocked(next))) {
> >               next = find_proxy_task(rq, next, &rf);
> > -             if (!next)
> > +             if (!next) {
> > +                     /* zap the balance_callbacks before picking again */
> > +                     zap_balance_callbacks(rq);
> >                       goto pick_again;
> > -             if (next == rq->idle)
> > +             }
> > +             if (next == rq->idle) {
> > +                     zap_balance_callbacks(rq);
>
> Also I would have preferred to have that zap_balance_callbacks() in
> proxy_resched_idle() but this is okay too.

So my initial hesitation here is just we call proxy_resched_idle() in
other situations where we might return NULL from find_proxy_task() as
well. So this avoids calling zap_balance_callbacks() twice.

But thinking some more, later in the full series we often call
proxy_resched_idle() in those paths where we are briefly dropping the
rq lock and we often call zap_balance_callbacks as well there. I'll
take a closer look at the full patch series and see if that doesn't
make sense to consolidate then.  Not 100% sure it will work out, but
worth looking into.

Thanks for the suggestion!
-john