From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 9FC34217705 for ; Fri, 10 Jan 2025 22:44:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736549060; cv=none; b=IcPRdjkZ72qxYukiv3SQeRL5bHpX/4ltme6DkR5uxIEUDJDlMjqEiXNF2pS6mx1ePOLuAe1G2zWpsQ9qxKJkiPhpxNT5vo/1WWjZZ9Z/TVAadPkSfazg40oTJoGkmsV5BOsTEzH8VKyc7T9IlHBoevcbT9P7CHcZgm3xJ161MBM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736549060; c=relaxed/simple; bh=TSswp+rWvE2kYIagjvVYbMKDatScl8D1joXwWs33uPU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FfxRqsg1djhEGXo59C8Q4Clv2eMpEjmEh4RxOH0zatUAXQTeAefDHOHOZYkBN3Wu6EW628OwERxqde0qKiuZBwoaeLHUqTvBj+UUR4iX+XuQyJ7K5n7O//yjHrYfIyPqCBPiOZ+RwTDMdpOW7Di8toSg/EU+8Tv6w96PEJoQKn4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mZQa/+FD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mZQa/+FD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 17681C4CED6; Fri, 10 Jan 2025 22:44:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736549058; bh=TSswp+rWvE2kYIagjvVYbMKDatScl8D1joXwWs33uPU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mZQa/+FDgOxhQe2r5iwhjs31dLXoYp35KoKYOhrIQl7ihMhyrKVR/MdbEB6mJGgai qN5CL1MkyKjSHVRnm3onsYdh8V+N+MIaczjYoAVFayj0gG3vIYX0Dyt9As/5NI0DSF p7OITlTzQs0fbA61rnAGt2a4vUFuRXdS3ViaOJAPZa0Xou6/iViecqtgYFLHL0S3Mm p0/+6JONN0zF42eAzfDtHsq22QhqhlP4gWX5NDePvBFQGV6kk8fye7T+MRWEA//e2E OmQXVo7qXZgdVsQ9OZE6Z85HOe3gjGkDr2MgCl6N5hNFS9T2MJWJz2yWOPOuIYK5eO OG2CslIQz+Rrw== Date: Fri, 10 Jan 2025 12:44:17 -1000 From: Tejun Heo To: Andrea Righi Cc: David Vernet , Changwoo Min , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , linux-kernel@vger.kernel.org Subject: Re: [PATCH v8] sched_ext: idle: Refresh idle masks during idle-to-idle transitions Message-ID: References: <20250110221631.52262-1-arighi@nvidia.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; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250110221631.52262-1-arighi@nvidia.com> On Fri, Jan 10, 2025 at 11:16:31PM +0100, Andrea Righi wrote: > With the consolidation of put_prev_task/set_next_task(), see > commit 436f3eed5c69 ("sched: Combine the last put_prev_task() and the > first set_next_task()"), we are now skipping the transition between > these two functions when the previous and the next tasks are the same. > > As a result, the scx idle state of a CPU is updated only when > transitioning to or from the idle thread. While this is generally > correct, it can lead to uneven and inefficient core utilization in > certain scenarios [1]. > > A typical scenario involves proactive wake-ups: scx_bpf_pick_idle_cpu() > selects and marks an idle CPU as busy, followed by a wake-up via > scx_bpf_kick_cpu(), without dispatching any tasks. In this case, the CPU > continues running the idle thread, returns to idle, but remains marked > as busy, preventing it from being selected again as an idle CPU (until a > task eventually runs on it and releases the CPU). > > For example, running a workload that uses 20% of each CPU, combined with > an scx scheduler using proactive wake-ups, results in the following core > utilization: > > CPU 0: 25.7% > CPU 1: 29.3% > CPU 2: 26.5% > CPU 3: 25.5% > CPU 4: 0.0% > CPU 5: 25.5% > CPU 6: 0.0% > CPU 7: 10.5% > > To address this, refresh the idle state also in pick_task_idle(), during > idle-to-idle transitions, but only trigger ops.update_idle() on actual > state changes to prevent unnecessary updates to the scx scheduler and > maintain balanced state transitions. > > With this change in place, the core utilization in the previous example > becomes the following: > > CPU 0: 18.8% > CPU 1: 19.4% > CPU 2: 18.0% > CPU 3: 18.7% > CPU 4: 19.3% > CPU 5: 18.9% > CPU 6: 18.7% > CPU 7: 19.3% > > [1] https://github.com/sched-ext/scx/pull/1139 > > Fixes: 7c65ae81ea86 ("sched_ext: Don't call put_prev_task_scx() before picking the next task") > Signed-off-by: Andrea Righi Applied to sched_ext/for-6.13-fixes. Thanks. -- tejun