From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 19C913612FC for ; Thu, 19 Mar 2026 11:22:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773919349; cv=none; b=PjgMw4tD9R2v0xDcnlVtxLd3QwrYhciHWzaSOX5LmrrE6ekyqAosJ04Oa6n5kIZnGBqv9j+Vy39houklvfdh4/flZssaY6O6pDLmRKyOR5mX7Lug77ciAF9FGw6On80aB7mO6HgVzEh1T4Ox9hO4cQcMYtFPcxyadkoObJirU8I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773919349; c=relaxed/simple; bh=43R/Qsmp0xoTZFZlkfj999jJx7BHZrZpZvIPWEWPMn8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZDgIDgYm9qsNesIhWM3yc7C2ExzWSrKVbkXQm8foYYJAJOU9oPIRqLg5M/wMtsExDyB5zITD03caJi8JCF8vsRipEgftDzG7W/omnTgwUW1E0QOCQMMb61DRIqOA80wLJBc0rXQqwlj3pNa4I/fvkG7swgVUbbKCoJm6YvN8fc8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=WIp2oU3U; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="WIp2oU3U" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=Whhfpz6PZXhlYSDQo5BMjQx8vH8J9B3FVoYVQ9YIhvQ=; b=WIp2oU3UvNZH/MJdVhVhSVnAYD PSQz1zfnsvceRAFeTyb71Ycsf+dsMQp0NJcLRjGellaP+lfdoQZQE38zUeauB2A0Yk2I75TLUsNT2 0fBoSJDksPYVmwxqOR2SUyhP67EvVPfBIoHomvnxFtqQ934zVsQW35SrrL4QNNMlAKIZ4Q2Z7GoCj t538Ao8EfYWgTvXLbrFmMMSpuYsbgSnmbk3AFY2dUyZSra+rq1ZDm4L3WzPIAytSuqF3BxXKe1hjB JCu+XWLQS2MH5g9S5JzCqD6nE06inEjwer4uct9xoi/JlmhtgLGREdEH1q5NtiKNejOc6kWjty1v9 wTAApYuw==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1w3BSE-0000000DLlh-3l2p; Thu, 19 Mar 2026 11:22:19 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 5B928300578; Thu, 19 Mar 2026 12:22:18 +0100 (CET) Date: Thu, 19 Mar 2026 12:22:18 +0100 From: Peter Zijlstra To: Uros Bizjak Cc: Tejun Heo , Xuewen Yan , mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, lukasz.luba@arm.com, linux-kernel@vger.kernel.org, rui.zhang@intel.com, di.shen@unisoc.com, ke.wang@unisoc.com, xuewen.yan94@gmail.com, Marco Elver Subject: Re: [RFC PATCH] sched: Add scx_cpuperf_target in sched_cpu_util() Message-ID: <20260319112218.GF3739106@noisy.programming.kicks-ass.net> References: <20260318121755.16354-1-xuewen.yan@unisoc.com> <20260318124718.GC3738786@noisy.programming.kicks-ass.net> <20260319090240.GS3738010@noisy.programming.kicks-ass.net> <20260319102655.GF3738786@noisy.programming.kicks-ass.net> <20260319111241.GG3738786@noisy.programming.kicks-ass.net> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260319111241.GG3738786@noisy.programming.kicks-ass.net> On Thu, Mar 19, 2026 at 12:12:42PM +0100, Peter Zijlstra wrote: > On Thu, Mar 19, 2026 at 12:02:29PM +0100, Uros Bizjak wrote: > > On Thu, Mar 19, 2026 at 11:27 AM Peter Zijlstra wrote: > > > > > > On Thu, Mar 19, 2026 at 11:01:03AM +0100, Uros Bizjak wrote: > > > > On Thu, Mar 19, 2026 at 10:02 AM Peter Zijlstra wrote: > > > > > > > > > That fastpath is definitely better; the slowpath is worse, but that is > > > > > in part because the compilers are stupid and cannot eliminate > > > > > static_branch(). > > > > > > > > asm gotos are implicitly volatile because they are control flow > > > > primitives. The compiler will *not* remove them. > > > > > > Yes, but I want ponies ;-) > > > > > > if (static_branch_unlikely(&foo)) { > > > if (static_branch_unlikely(&foo)) { > > > /* A */ > > > } else { > > > /* B */ > > > } > > > /* C */ > > > } > > > > > > Is a very common occurence. And we all know this really should be: > > > > > > if (static_branch_unlikely(&foo)) { > > > /* A */ > > > /* C */ > > > } > > > > > > So how can we make this happen? IMO marking those functions __const > > > should tell the compiler that yes, it can elimintate them. > > > > Huh, __const promises that the function does not access global memory > > and that the function does not have side effects other than returning > > a value. asm volatile inside the __const function creates a side > > effect, so removing function calls would be considered a > > misoptimization. Probably this could lead to undefined behavior in > > terms of what the compiler expects from a __const function. > > So since the whole function reduces to a single branch or nop, it does > not in fact access memory or have side effects, right? > > (and there is still __pure, for if we somehow consider the key governing > the text patching to be an 'access' in this case) So is it really just the problem that since the compiler doesn't know what asm volatile ends up doing, it must assume the worse and hence invalidates the __const (without a warning even). So you're letting the unknown weight heavier than the explicit instruction from the author who put on __const (and supposedly does know). And I feel somewhat strongly that this is wrong. Yes, if the author gets it wrong, and there are side effects and things are elided it is a misoptimization, but that is on the author. You can't blame the compiler for doing what it was told to do. Or is there really more to this?