From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 383B82376E0 for ; Thu, 11 Dec 2025 16:15:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765469752; cv=none; b=bw7qcxyiucqe20R0+LwFRedNOf6VXPbXsNngcX+6mUtjKdY5KL43ub/fG4zhAAMIm8C+b/PRRL5GxpC1DEa42zctdsHjsN+acWdEA2Lwqi3HoFjviWP9RSmmyFrlQaL06ETd67dhVN2mGWEfwSmSCVpK+F9NxfNbIcjRaaudfRA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765469752; c=relaxed/simple; bh=lUvXrqwZGw/Bs2F/Kj7aKi3qiLK4BDCJxLKCUlD9izQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=QpJIutlZyfIlEEWqtlVl4EY2BSLsTdbZA0q5r/Dd33TZ7MyUfGUjQ+/1bXMISlcOqlNT/ElG66sjjK8HiE+7+SrxP40Kq4REO4MBhQly37MC0807L3OGa8zDs9u6BQxRn0pcJwrcg+NNBb1WM8BWW8M2hVDSb3NuvGGMyURIm8Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4EF211063; Thu, 11 Dec 2025 08:15:42 -0800 (PST) Received: from [192.168.178.6] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 630C13F73B; Thu, 11 Dec 2025 08:15:47 -0800 (PST) Message-ID: Date: Thu, 11 Dec 2025 17:15:45 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 2/2] sched: update the rq->avg_idle when a task is moved to an idle CPU To: Huang Shijie , mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org Cc: patches@amperecomputing.com, cl@linux.com, Shubhang@os.amperecomputing.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, linux-kernel@vger.kernel.org, vschneid@redhat.com, vineethr@linux.ibm.com, kprateek.nayak@amd.com References: <20251209094508.570049-1-shijie@os.amperecomputing.com> <20251209094508.570049-3-shijie@os.amperecomputing.com> Content-Language: en-GB From: Dietmar Eggemann In-Reply-To: <20251209094508.570049-3-shijie@os.amperecomputing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 09.12.25 10:45, Huang Shijie wrote: > In the newidle balance, the rq->idle_stamp may set to a non-zero value > if it cannot pull any task. > > In the wakeup, it will detect the rq->idle_stamp, and updates > the rq->avg_idle, then ends the CPU idle status by setting rq->idle_stamp > to zero. > > Besides the wakeup, current code does not end the CPU idle status > when a task is moved to the idle CPU, such as fork/clone, execve, > or other cases. In order to get more accurate rq->avg_idle, > we need to update it at more places(not only the wakeup). > > This patch introduces a helper: update_rq_avg_idle(). > And uses it in enqueue_task(), so it will update the rq->avg_idle > when a task is moved to an idle CPU at: > -- wakeup > -- fork/clone > -- execve > -- idle balance > -- other cases [...] In v2 you moved update_rq_avg_idle() (1) from activate_task() (2) to enqueue_task() to possibly handle delayed tasks. In v3 you figured there can't be any delayed task on a CPU when it sets rq->idle_stamp in sched_balance_newidle() So you could move (1) back to (2) avoiding the 'if rq->idle_stamp' for the sched_change pattern for instance? I tried to understand whether this patch could help with one issue we currently have with 'DCPerf Mediawiki' benchmark where on 2 comparable servers, one has a 10% lower CPU utilization and I traced it down to significantly different behaviour in sched_balance_newidle() and further down to: if (!get_rd_overloaded(this_rq->rd) || this_rq->avg_idle < sd->max_newidle_lb_cost) where the one with the lower CPU utilization bails out way less often (because this_rq->avg_idle is very high, system is overloaded). But I failed so far. Anyway, we'll use this patch for another test run right now.