From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gentwo.org (gentwo.org [62.72.0.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 87A083A6B8D for ; Fri, 7 Aug 2026 20:24:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.72.0.81 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786134263; cv=none; b=kcBOiyaXuRdG9nRwk4i6oUWaZ+MW2owRoTCs2n5e1L1LQPq8pIb5/jZfEcpSFr1IAnBEfYaUSdYz/0Re21VlTTmxeMgGvpaluY/Pl2maQJRrjmn+4DC0jDygqYT1DaDgIKtjv3Jmzj7MC/eBFkdLVsRc2oKv0jvnD9fdvPxP2PA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786134263; c=relaxed/simple; bh=kdUEE6rAU3UB9T5KIDDJeISnvKNPaoYm70E1ouOkdFE=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=b/3si2KKsuHRFvyR5U2VQzcJR606szpIFXbQdFYcyd5AU5n0HpjORMEhUzxAQ7uXxupHXjlHyeZxP377HujNt6LJ+mteS49d/XzvA5GupcGG240AIJ+kNdq2yDHR5Qqq6aByGhdm3zSPO7rcGvUfLmxusJPjQgl1nlZvTb90F7k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=gentwo.org; spf=pass smtp.mailfrom=gentwo.org; dkim=pass (1024-bit key) header.d=gentwo.org header.i=@gentwo.org header.b=ZWEBLFc7; arc=none smtp.client-ip=62.72.0.81 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=gentwo.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gentwo.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=gentwo.org header.i=@gentwo.org header.b="ZWEBLFc7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.org; s=default; t=1786134261; bh=kdUEE6rAU3UB9T5KIDDJeISnvKNPaoYm70E1ouOkdFE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ZWEBLFc7v6uP0raInZxY75ov2zuLT6NlJ6wDKkCNrJAUTIkAN62WERpdaxGZfoRy6 OJ6ceImAp9PSscnGc0c1RWX1ZLhq+4UhsEJMalAMbTU2Pe7VYjYvBJ43L5YAJuPd+i 1spx9iGmukfTYhL0nWZezG5l9g0v43Ebcl2Aid5E= Received: by gentwo.org (Postfix, from userid 1007) id 9DD5C41AE5; Fri, 07 Aug 2026 13:24:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 9B7B140EBA; Fri, 07 Aug 2026 13:24:21 -0700 (PDT) Date: Fri, 7 Aug 2026 13:24:21 -0700 (PDT) From: Shubhang To: Zhan Xusheng cc: Zhan Xusheng , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , John Stultz , Christopher Lameter , Shubhang Kaushik , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] sched/core: Skip rq->avg_idle update without a valid idle_stamp In-Reply-To: <20260807024541.1136441-1-zhanxusheng@xiaomi.com> Message-ID: <4e6582d5-340d-9e61-cabd-a09cd2536bc4@gentwo.org> References: <20260806-master-v2-1-e1f3a1a0c903@gentwo.org> <20260807024541.1136441-1-zhanxusheng@xiaomi.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII 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