From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id E7B5035B64B
	for <linux-kernel@vger.kernel.org>; Mon, 23 Feb 2026 10:23:58 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1771842240; cv=none; b=pXq5WKaaZCHqF9edP/fd4dnv+S2QLNi2MCtsxdxrmnLjtVbh0w1AIbtusmdg79ACg/I1uo5CHV/F3sc4YtlUApJD8WlQPI7bEBR156012761V53I231JAhK0MzLmADlNakXGwW/008mSU4fGFHEh9JLNh4jF1SbWbsYojr8X3aM=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1771842240; c=relaxed/simple;
	bh=R8817XzHl02HPVDoWXQOyCdqSmf+Vg1/KdDL1nYcop4=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=kFMbmiWjGCZmMb7WfOIu0kmMTluMTv0E+vylReVxmPZpnl+9TmmgTkXTy5Tgqn293Ya0SOiuu2jLM8OZDYR7iR6/mPl1MeQj2KBoSXLBFPu+Vtsi+HeBCy2bAAfiwOQfmuxe4UUk7It3kqHUrXTaUGe7kKv3Yu9gUmwRm65lPY0=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
	by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1D6B8339;
	Mon, 23 Feb 2026 02:23:52 -0800 (PST)
Received: from [10.57.71.137] (unknown [10.57.71.137])
	by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0EA233F59E;
	Mon, 23 Feb 2026 02:23:55 -0800 (PST)
Message-ID: <5b13fda8-183d-4076-bdd3-f85b5d6791fd@arm.com>
Date: Mon, 23 Feb 2026 11:23:54 +0100
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/7] sched/fair: Fix lag clamp
To: Peter Zijlstra <peterz@infradead.org>, mingo@kernel.org
Cc: juri.lelli@redhat.com, vincent.guittot@linaro.org, rostedt@goodmis.org,
 bsegall@google.com, mgorman@suse.de, vschneid@redhat.com,
 linux-kernel@vger.kernel.org, wangtao554@huawei.com, quzicheng@huawei.com,
 kprateek.nayak@amd.com, dsmythies@telus.net, shubhang@os.amperecomputing.com
References: <20260219075840.162631716@infradead.org>
 <20260219080624.830623197@infradead.org>
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
Content-Language: en-GB
In-Reply-To: <20260219080624.830623197@infradead.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 19.02.26 08:58, Peter Zijlstra wrote:

[...]

> @@ -761,17 +763,16 @@ u64 avg_vruntime(struct cfs_rq *cfs_rq)
>   * EEVDF gives the following limit for a steady state system:
>   *
>   *   -r_max < lag < max(r_max, q)
> - *
> - * XXX could add max_slice to the augmented data to track this.
>   */
>  static void update_entity_lag(struct cfs_rq *cfs_rq, struct sched_entity *se)
>  {
> +	u64 max_slice = cfs_rq_max_slice(cfs_rq) + TICK_NSEC;
>  	s64 vlag, limit;
>  
>  	WARN_ON_ONCE(!se->on_rq);
>  
>  	vlag = avg_vruntime(cfs_rq) - se->vruntime;
> -	limit = calc_delta_fair(max_t(u64, 2*se->slice, TICK_NSEC), se);
> +	limit = calc_delta_fair(max_slice, se);
>  
>  	se->vlag = clamp(vlag, -limit, limit);
>  }

nitpick:

The "Limit this to either double the slice length with a minimum of
TICK_NSEC ..." in the function comment header doesn't match anymore.