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 D75561B21BD for ; Fri, 3 Jan 2025 21:39:52 +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=1735940392; cv=none; b=HLrjUwm4j3z47mMVBeRR7F7rtmiJLPPayWF5cP7RT/BJmfO/Bh+6+7RdO9ZsSshU60c38jAxHrzNoXquccjeBFg5WqWuf52niVxUDtPUAlLUvVdeoelwVltW/OuSKt/3JunJqmvE9zPDFkR/BVHJZmIqOcbLXlwlAXe6sDRbceI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735940392; c=relaxed/simple; bh=4obijk2TvufEOmojMDIe/15LMARaUf2BsZO7svNGUKk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HCAy2Bqg7QY8F8+DPdB6tVPw+E3v6CWuetoonVx8wIcnqwWymhdyF5flLI0bHnFIt0jv1EzuznEODJpALRgGf87JVLO+B4041jjJzS0Q7c3f+Hs8MmGRppesUz9EHm800LKxOm6pnGNObW3ciIjLxkmR+KBJ0f0uWsWmU7uhmK4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lYcWy4T1; 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="lYcWy4T1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5BECFC4CECE; Fri, 3 Jan 2025 21:39:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1735940392; bh=4obijk2TvufEOmojMDIe/15LMARaUf2BsZO7svNGUKk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lYcWy4T1BDkOE8KiHmTuy6Yh0Zn8B2SSlkypjXhgJY4YSdDUnku/pdEwTe+7SLGl6 S4+9D7AaRqKeQEcEGzDmEUNZE3bOId5MB741S1QxYemPFTE91u9v8wZ45iHJat/dSH SnrF7g8z3z0xMPn6J+WifDDBAugFGnTMHogvP4uXsA42QRDhJZe69OBqoIy+jk1Rod XbhZ2i+/4JgoOppFM9iZ32fiI2DV9wxd0VA3sL3sV7Nf9k6nh/QYAzS3YLHXpaEkKA k0XX0qR656HdVOWQdcBs1MQ4J0PWPe5fMw9wV4sta/qMIrq3mSa/siInvlUe1SHFOp AIPzNssk/Xdpg== Date: Fri, 3 Jan 2025 11:39:51 -1000 From: Tejun Heo To: Andrea Righi Cc: David Vernet , Changwoo Min , linux-kernel@vger.kernel.org Subject: Re: [PATCH] sched_ext: Refresh idle state when kicking CPUs Message-ID: References: <20250101182449.21517-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: Hello, On Fri, Jan 03, 2025 at 09:55:14AM +0100, Andrea Righi wrote: ... > > When the put_prev/set_next paths were reorganized, we lost the signal on the > > CPU re-entering idle from idle. However, that signal is still available if > > we hook into idle_class->pick_task(), right? So, if we move > > update_idle(true) call there and make sure that we don't generate an event > > on busy->busy transitions, we should be able to restore the previous > > behavior? > > Which is basically what I did here: > https://lore.kernel.org/lkml/20241015111539.12136-1-andrea.righi@linux.dev/ > > We didn't fully like this, because it'd introduce unbalanced transitions, > as update_idle(cpu, true) can be generated multiple times. But it's > probably fine, at the end we would just restore the original behavior and > it'd allow to solve both the "pick_idle + kick CPU" and the "kick from > update_idle()" scenarios. > > If we like this approach I can send a new patch updating the comment to > better clarify the scenarios that we are trying to solve. What do you > think? Maybe we can solve the unbalanced transitions by tracking per-cpu idle state separately and invoking ops.update_idle() only on actual transitions? Thanks. -- tejun