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 E5366283FDD for ; Tue, 2 Dec 2025 10:24:42 +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=1764671085; cv=none; b=l0zepMfIsz0InnazML5OAVFZwQTMQfsSAs5fAZsej/+efYWAzYo5bAXpfuBLR95zjKViRyOS+kVUMVgZUI269Al4LQkTaojQwCfRrEP3af9B1thfqeBqPIvjADcKspHsmhsrk4zIzGJSiEpijPvjDc8vTg3W9bYzYqWEJd5mxHs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764671085; c=relaxed/simple; bh=vdWhmyfB52h13HP/dHyH0uGGx/p6NYv8E2HjWXOsSzY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qOPgZ/b8/BSG79aJuw0Cd7M1Q4TRRqiFOrD2GcsogBd3T4Up9mlag6Z19XvW/iyKUCchzuOjGw1zo/9LXAdPcXef8A6U440msmmZ39uquf0vHb1ze9qum/7bLtgsFAKuKHAuef/sto/eumRFdW/OW1eB4X/UbDyrQWd40k5tdzk= 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=RrH5Dl2i; 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="RrH5Dl2i" 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=vdWhmyfB52h13HP/dHyH0uGGx/p6NYv8E2HjWXOsSzY=; b=RrH5Dl2iV2mws6pe1bHe7uxcDh OtoYgooEailHsdFoZdIG+udJYu0IhNcFSdTJxbhNv2GOeZakcJsvk5b0DQ7LdLHa/L79wyC5bbdDu B5i0pyVoHYPgyvjDLPK7XmodFi6VP+HKiwvLi/c/DBHIGjvWuxxn1mvjkL8oSuaRjkru56fE9Blqx PL2ieiCwPLvE4mbZ2qJpxSa9wdi+o0e5MECKpe3fJzxgeReWjGTd50egHUVrr+MqE6JBvdqrml247 8qWprIeSlSOVmJigez/jPWQZ/6S45xGt9QnGBdMPAgfItJxl6LtWNyeA22+3ADuQiNQghQIUoW4FE nQImPlrg==; Received: from 2001-1c00-8d82-9800-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d82:9800:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vQMh9-0000000076h-3kHS; Tue, 02 Dec 2025 09:29:16 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 74CEF3005E0; Tue, 02 Dec 2025 11:24:35 +0100 (CET) Date: Tue, 2 Dec 2025 11:24:35 +0100 From: Peter Zijlstra To: Ingo Molnar Cc: linux-kernel@vger.kernel.org, Juri Lelli , Dietmar Eggemann , Valentin Schneider , Vincent Guittot , Shrikanth Hegde , Linus Torvalds , Mel Gorman , Steven Rostedt , Thomas Gleixner Subject: Re: [PATCH 4/6] sched/fair: Rename avg_vruntime() to cfs_avg_vruntime() Message-ID: <20251202102435.GA2556898@noisy.programming.kicks-ass.net> References: <20251201064647.1851919-1-mingo@kernel.org> <20251201064647.1851919-5-mingo@kernel.org> 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: <20251201064647.1851919-5-mingo@kernel.org> On Mon, Dec 01, 2025 at 07:46:45AM +0100, Ingo Molnar wrote: > Since the unit of the ->avg_vruntime field isn't actually > the same thing as the avg_vruntime() result, reduce confusion > and rename the latter to the common cfs_*() nomenclature of > visible global functions of the fair scheduler. But you're going to rename both those fields into sum_weight and sum_w_vruntime freeing up the avg_vruntime name and clearing up the above confusion. So why then still rename the thing? The result of the function really is the (weighted) average of the vruntime, so the naming isn't confusing or bad (unlike the variables it uses, which are pretty badly named).