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 70C2653BE for ; Mon, 27 Jan 2025 20:01:42 +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=1738008102; cv=none; b=m+dHYNv/9Fg4bi0txTkduIn5GaIVQX7M1vqlPxVhd6htZYXcoNExtKyd/pIQa9BFeFu4+rO48XN9RzZBQHr2pG6g6bTJtAl42lZppBaKZDhmwIR+h8BvH02gHX3vK5NJ7cHXNsEAzQBsyk3N6l1LBEwqfeNKRh1tAF86ZQNFEd8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738008102; c=relaxed/simple; bh=bp6OPUCPZx0+m4N62Pg/tGitu3G9izdVr9bNMZSRWW4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FcS6Vqivh8uvFNMEl6xv/kXydPYYljDAscaKcotyNhe2ocSvOukRQ7pCIOcjTWJaiWGBX5T0TrMgZXrWBnK8DvXoGRW0Bp7R1LL6oZ+W8FjqtusZkuvhWF9wagMrtQv/7crtG8hStZhmQfSM8LN3pS464MgaPRuwFALj901CjL8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Dy0olwM0; 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="Dy0olwM0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BE563C4CED2; Mon, 27 Jan 2025 20:01:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738008101; bh=bp6OPUCPZx0+m4N62Pg/tGitu3G9izdVr9bNMZSRWW4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Dy0olwM0hanwdjGrBXfjU+UntyV/ZAIvf6JeJxtoCD69AfSV2iFI9XXn3KoUSj3dd u9/+67d9ompYGtF+OTCfQ1D9EqnOziHe3zWtxtN+fL0R0XzZJu9EJPi0NgKKBZDajU MT5mpk3vdrx0wkHjx75FlMPsBR0ZxbHl0X7QnG4Qu/mZSrvsbOnWerDbQV907JLWgA G9idWgv4hIFsCON8dJ4snQ2KO8JAR7VJkcZ9ZO1dmrhai0wCtX4Zr0NAMBGcoSTvE9 Ra3Tooib1z9G9WPINVmNhFRnLp6oVOJJr1MHd2TwhFrHf54C86Q4mKQMwuh4YT7sZ8 eHAloF9gLQq4Q== Date: Mon, 27 Jan 2025 10:01:40 -1000 From: Tejun Heo To: Changwoo Min Cc: void@manifault.com, arighi@nvidia.com, kernel-dev@igalia.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 03/11] sched_ext: Add an event, SELECT_CPU_FALLBACK Message-ID: References: <20250126101614.232388-1-changwoo@igalia.com> <20250126101614.232388-4-changwoo@igalia.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: <20250126101614.232388-4-changwoo@igalia.com> Hello, On Sun, Jan 26, 2025 at 07:16:06PM +0900, Changwoo Min wrote: ... > struct scx_event_stats { > + /* > + * If ops.select_cpu() returns a CPU which can't be used by the task, > + * the core scheduler code silently picks a fallback CPU. > + */ > + u64 SELECT_CPU_FALLBACK; As C has one global namespace, we're gonna have to prefix these. Hopefully, something not too long. SCX_EV_? > @@ -3663,6 +3668,10 @@ static int select_task_rq_scx(struct task_struct *p, int prev_cpu, int wake_flag > cpu = SCX_CALL_OP_TASK_RET(SCX_KF_ENQUEUE | SCX_KF_SELECT_CPU, > select_cpu, p, prev_cpu, wake_flags); > *ddsp_taskp = NULL; > + > + if (unlikely(!is_cpu_allowed(p, cpu))) > + __scx_add_event(SELECT_CPU_FALLBACK, 1); This is trying to guess what select_task_rq() is going to do and then count that as an event, which doesn't seem great. Can't we just record the picked CPU here into a field in p->scx and then compare that against cpu_of(rq) in enqueue_task_scx()? That way, we can reliably count events where CPU selection was modified by the fallback logic regardless of why or how that happens. Thanks. -- tejun