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

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.

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

Thanks,
Zhan Xusheng