Re: [PATCH v2] sched/core: Skip rq->avg_idle update without a valid idle_stamp

[Shubhang]

Hi Zhan,

On Fri, 7 Aug 2026, Zhan Xusheng wrote:

> On Thu, 06 Aug 2026 17:26:27 -0700, Shubhang Kaushik (Ampere) wrote:
> > This can happen when the scheduler switches to the idle task through a
> > path that did not set rq->idle_stamp via newidle_balance(), for example
> > during find_proxy_task() or force-idling.
>
> There is a path that needs no config option, and I suspect it is what
> your hackbench tracing actually hit: sched_balance_newidle() returns
> before it stamps.
>
> 	if (this_rq->ttwu_pending)
> 		return 0;
> 	...
> 	this_rq->idle_stamp = rq_clock(this_rq);
>
> The early return sits above the assignment, and its own comment says the
> task will be enqueued when switching to idle.  So the rq goes idle with
> idle_stamp == 0 and leaves idle again as soon as the pending wakeup is
> processed, which is exactly when put_prev_task_idle() consumes the
> stamp.  A wakeup-heavy load like hackbench should hit that constantly,
> whereas find_proxy_task() and force-idling need proxy exec or
> CONFIG_SCHED_CORE.  (Force-idle is the sched_core_enabled(rq) return at
> the idle: label in pick_next_task_fair(), which is also above the
> newidle call.)
>
> Worth naming ttwu_pending in the changelog?  It makes the bug
> config-independent, which seems relevant given the Fixes: tag.
>
> The fix itself looks equivalent to what 4b603f1551a7 removed: the old
> ttwu_do_activate() code was wrapped in if (rq->idle_stamp), and skipping
> the trailing rq->idle_stamp = 0 is a no-op when the stamp is already
> zero.  update_rq_avg_idle() has just the one caller, so nothing else
> changes.

Thanks for the suggestion, that makes sense. The ttwu_pending path is a 
better example since it does not depend on proxy exec or core scheduling, 
and it is likely what hackbench hit.

I will update the changelog to lead with sched_balance_newidle() 
returning before setting idle_stamp when ttwu_pending is set.

> Nit: unlikely(!idle_stamp) may be the wrong way round if ttwu_pending is
> the common trigger.

Ack.

> Thanks,
> Zhan Xusheng

Regards,
Shubhang Kaushik