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 9336024B246 for ; Fri, 10 Jan 2025 19:39:10 +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=1736537950; cv=none; b=MVTexQBgtuX21Jv4OEsU5Z/9kK6ZUUTdiMZGhi7pFAU13CZN8M1ux4E7lHVGDENBkPx3NuudolTDz3Unzud+Ptf9PtDSix2f/V8mj2xMF9eHzWEhtPPBSZCI5TWQTr+DeOTopi7JQKagxQut4en28W3pv/xIuG18bZb75xpcMtM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736537950; c=relaxed/simple; bh=HL+tHsXuN/2sFprv2LHIg7B3muDM6wIhACuj+/Bfkbo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=n8DSuyZbQlX4uvi2jjWFqzYUGbrK4tAqIJI9M5FQJRzg2vlDF5Hur0x2BODgFJE+Z2VLpzayFqU9eupIW0czUOWIdLiB1uiJGoxLCPMLgen2TPTSER/GNO91NTFvfIgoTDW9Bsa2OnsgdDMDbE9SAAJjCpgfj7BJkSyZ14opy6E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cKj7o79j; 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="cKj7o79j" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0DA8CC4CED6; Fri, 10 Jan 2025 19:39:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736537950; bh=HL+tHsXuN/2sFprv2LHIg7B3muDM6wIhACuj+/Bfkbo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cKj7o79jqtpLRKIBUBB6Xc4VSLqNT1PnC4AXLXbJydUKhxSIogFhJ1VFoz1XKf3jC rxAfDPBnTxtDJ3+eAt0G34Em7Vb8Sa/CmxHB4el8RVdFu7YCZ3MpfSdscFS7lzqTyE VEv5q3IHhwLs8C/a5L38y8OoOjLQ2CN5/YTzbjnT+beeqI+F74G3PFXkiEomuw1+P8 uypyTGuOuEb/J/4fQ14JM48nF5kaag1lBRzRZVtVbaI0o9Wqhkc3Eue1e3wubu1lDb w58Rjv/m2Wf8nVmCXIIc/kSqQQQXlAxC5LCR2uPrmiox+E03MFCBCEPkRnv8xko+8P 7Eij1k49XphvA== Date: Fri, 10 Jan 2025 09:39:09 -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 v6] sched_ext: idle: Refresh idle masks during idle-to-idle transitions Message-ID: References: <20250110084625.562316-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: <20250110084625.562316-1-arighi@nvidia.com> Hello, Andrea. On Fri, Jan 10, 2025 at 09:46:25AM +0100, Andrea Righi wrote: ... > + if (do_notify) { > + if (SCX_HAS_OP(update_idle) && !scx_rq_bypassing(rq)) > + SCX_CALL_OP(SCX_KF_REST, update_idle, cpu_of(rq), idle); > + } else { > + bool is_prev_idle; > + > + /* Refresh idle masks during idle-to-idle transitions */ Can you add a bit more explanation on what case this path is handling here or in the function comment? The function comment explains what it's about but doesn't quite explain the exact sequence which isn't very intuitive. > + rcu_read_lock(); > + is_prev_idle = is_idle_task(rcu_dereference(rq->curr)); > + rcu_read_unlock(); > + > + if (!is_prev_idle) > return; This function is always called under the rq lock, right? We can assert that and skip the rcu dancing. > } > > + if (!static_branch_likely(&scx_builtin_idle_enabled)) > + return; Would structure like the following be better? It makes clear that the last condition checks are for the builtin idle path. if (SCX_HAS_OP(update_idle) && do_notify && !scx_rq_bypassing(rq)) // call ops.update_idle(). if (!scx_builtin_idle_enabled || (!do_notify && !is_idle_task(rq->curr))) return; Thanks. -- tejun