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 DAEF63DCDBB for ; Fri, 29 May 2026 12:02:06 +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=1780056129; cv=none; b=F77nUn7q7AEJRwQ8ntZuUd2vGuzsCM+R69dthJH2xk73TJJaWqzIdu13NPtMKXe00BNyPbIFqcEfCj0mZqtOWZryEN5FiXAFCM+TWkPyoWqyBXVg31J5xz3PSOW6UJaFUiR6wLQoZ4CQZPBj02GDyPYOCpF/P61ry9j0G8VLE9o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780056129; c=relaxed/simple; bh=vhVqvX2YitrqfMHspmoLuutg1woCZRGoE7Ac0UZUSaw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=G8Y6aCLI63SoU9Vajodst6bbLy42nCEUrN5TIqO6mc6pRS7vtK4H5mK838BqJ3mBGWvZf5S8xO4iLQF9xkefEICWHGi7Y1lAG3U1juQs6fnQly0lynT0WGxYW87HbgfIDTP/swgOr06w6+BBOKn4yUFQ3FtVG6OERjHPsWKZhHk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=HSIpTv4i; 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=pass 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="HSIpTv4i" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=DYjNtjM53R2Uc+O4d74KyaRdeRnlLZ3sD6nyBCORBrI=; b=HSIpTv4ihwLc1mW0A+gPTkYQLN fR5KyavgTOMsYa4P0+Cd3/NEYrq0ItYbv66CAH0llSriSv3Q3OS8+U82USJKkv8J1O5vdufQmz8+P 3CsulroGk7XcDdfkyWCIdo4x0dt9plkAlhkMrc0vvMGhiFcluGDYBDNZLAJAUSHSmSalMd0yg6mEe g7PoI3qfON+gEU0/jZ3EwJysswczP5Vg0I0pVxUM1+FSkTvKzPZhM6s0kVcyA6K19KI9Qcp98vDOO kLw2I/OrLOguGxCNishpKpfxMo8LO5NBSHJFvAgWd74j0znP86jCUh8ckSfj8VIjJ+bX6nUrfGY3K iOtTHqPg==; Received: from 2001-1c00-8d85-4b00-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:4b00:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wSvuS-00000001E7Y-31Rg; Fri, 29 May 2026 12:01:53 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id B787530036F; Fri, 29 May 2026 14:01:51 +0200 (CEST) Date: Fri, 29 May 2026 14:01:51 +0200 From: Peter Zijlstra To: Hongyan Xia Cc: Li kunyu , "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" , "kprateek.nayak@amd.com" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] kernel/sched/fair: Fix to not require calculation for the weight nice0 Message-ID: <20260529120151.GM3493090@noisy.programming.kicks-ass.net> References: <20260529023413.482020-1-likunyu10@163.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: On Fri, May 29, 2026 at 07:37:07AM +0000, Hongyan Xia wrote: > On 5/29/2026 10:34 AM, Li kunyu wrote: > > Typically, the default priority for client tasks is nice0, and reducing > > the conversion of virtual runtime to real time for nice0 tasks can > > significantly reduce unnecessary computations. > > > > Signed-off-by: Li kunyu > > --- > > kernel/sched/fair.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 69361c63353a..74d1c77a8bcf 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -7033,7 +7033,10 @@ static void hrtick_start_fair(struct rq *rq, struct task_struct *p) > > resched_curr(rq); > > return; > > } > > - delta = (se->load.weight * vdelta) / NICE_0_LOAD; > > + if (unlikely(se->load.weight != NICE_0_LOAD)) > > + delta = (se->load.weight * vdelta) / NICE_0_LOAD; > > + else > > + delta = vdelta; > > > > /* > > * Correct for instantaneous load of other classes. > > Given NICE_0_LOAD is a nice power-of-two which compiles down to just a > bit shift, it seems interesting that you would find the multiplication > to be 'significant unnecessary computations'. Do you have any data to > support this? Notably, branches can be many times more expensive than a mult on modern deeply pipelined machines. Divisions are a bit of a mixed bag, but mult is generally dirt cheap. According to Gemini we have something like so: +---------------------------------------------------------------------------------------------------+ | ARCHITECTURE | BRANCH MISPREDICT PENALTY | 64-BIT INTEGER MULTIPLY | 64-BIT INTEGER DIVIDE | | (Modern Cores) | (Clock Cycles) | (Latency / Throughput) | (Latency / Throughput) | +-------------------+----------------------------+-------------------------+------------------------+ | | | | | | Apple M-Series | 16 to 20 cycles | 3 to 4 cycles | 7 to 9 cycles | | (M1 through M5) | | 0.5 cycle thr. (2/clk) | 2 cycles throughput | | | | | | +-------------------+----------------------------+-------------------------+------------------------+ | | | | | | Intel Core | 14 to 15 cycles * | 3 cycles | 18 to 25 cycles | | (Panther / Arrow) | | 1 cycle thr. (1/clk) | 10 to 15 cycles thr. | | | | | | +-------------------+----------------------------+-------------------------+------------------------+ | | | | | | AMD Zen | 17 to 20 cycles | 3 cycles | 12 to 14 cycles | | (Zen 4 / Zen 5) | | 1 cycle thr. (1/clk) | 3 to 4 cycles thr. | | | | | | +-------------------+----------------------------+-------------------------+------------------------+ So the branch in calc_delta_fair() might still be justified, esp. if it is predicted well. But like Hongyan noted, not in this case.