From nobody Thu Apr 2 20:25:30 2026 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 6286033987F for ; Thu, 19 Feb 2026 08:11:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771488664; cv=none; b=qsBxpDFleiHPmdgd+fAH5UByFBIBcTGBsUQzVeW0H0fsPEEM3DD3OFTfhI90nHQHv+t8NzaqmAPGP82f8ass0dR+H5XT0pyWQG3mxE69iHuzZ+9lfei4syaBdXs2Q8iL1AwRLT/kT03lFriR4xYzkeOg+WL88YOagsokMbIr4F8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771488664; c=relaxed/simple; bh=qxePsahSSTni7pOnj/8ZO65j5ulK9XCO82OomD6NCy8=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=so2uhwN8pWZDx1VFSPNC8WEQdexmD74KshU5LzFbUmz813rA+oDEevRQuLVvUaqko2I9XikAqXHu1TSNDwhr5iAM/ErPTS13zrqIW+vdF1YE7qsthdx//5IRGfKdifBadXZn/7Cd7mTbrxuFRwUQ4B9N24ElTko15ZDpl/5bb3I= 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=Ar0GhbGk; arc=none smtp.client-ip=90.155.50.34 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="Ar0GhbGk" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Type:MIME-Version:References: Subject:Cc:To:From:Date:Message-ID:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:In-Reply-To; bh=dvs/8tMoN6rh7xHDWuQUS6D+qWuuXZ76GRKBxZUxnXY=; b=Ar0GhbGkWctusDpyd70/E7esiz z+cGdo/WpEHDI7epQ5BnVB9u6gJwnYov4Ws5sYiDLaPiWBAPGLdA6c9rPHXLOzPbzqwax1S3nq/uv AH7ZhryjyhhNk8S9XzaHMUPbb34GoTh+3QCg0jlGFZ0RW5dfwzPyH7m0iYdLGTpICbpJrgt3Pn+f1 Y3xW0TTPgVb6cAnhB4yK84k1Gb2dM80lpNnGtNstKijApwa7C+IBGkwkZVMpuWDIGt3PSYlPdsw8i GAAO4xLZuAXueh2GpEQMuF37hcZ7vAr94Nn0sGUK8XA6mjXR+imyBFkYckzagWsYO/iCt4Ay2WAPd Br744F4w==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vsz7Z-00000007KIz-3sF4; Thu, 19 Feb 2026 08:10:50 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 0) id C321D30332E; Thu, 19 Feb 2026 09:10:48 +0100 (CET) Message-ID: <20260219080624.715897842@infradead.org> User-Agent: quilt/0.68 Date: Thu, 19 Feb 2026 08:58:43 +0100 From: Peter Zijlstra To: mingo@kernel.org Cc: peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, 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, Zhang Qiao Subject: [PATCH v2 3/7] sched/eevdf: Update se->vprot in reweight_entity() References: <20260219075840.162631716@infradead.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Wang Tao In the EEVDF framework with Run-to-Parity protection, `se->vprot` is an independent variable defining the virtual protection timestamp. When `reweight_entity()` is called (e.g., via nice/renice), it performs the following actions to preserve Lag consistency: 1. Scales `se->vlag` based on the new weight. 2. Calls `place_entity()`, which recalculates `se->vruntime` based on the new weight and scaled lag. However, the current implementation fails to update `se->vprot`, leading to mismatches between the task's actual runtime and its expected duration. Fixes: 63304558ba5d ("sched/eevdf: Curb wakeup-preemption") Suggested-by: Zhang Qiao Signed-off-by: Wang Tao Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Tested-by: K Prateek Nayak Tested-by: Shubhang Kaushik Link: https://patch.msgid.link/20260120123113.3518950-1-wangtao554@huawei.c= om --- kernel/sched/fair.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -3814,6 +3814,8 @@ static void reweight_entity(struct cfs_r unsigned long weight) { bool curr =3D cfs_rq->curr =3D=3D se; + bool rel_vprot =3D false; + u64 vprot; =20 if (se->on_rq) { /* commit outstanding execution time */ @@ -3821,6 +3823,11 @@ static void reweight_entity(struct cfs_r update_entity_lag(cfs_rq, se); se->deadline -=3D se->vruntime; se->rel_deadline =3D 1; + if (curr && protect_slice(se)) { + vprot =3D se->vprot - se->vruntime; + rel_vprot =3D true; + } + cfs_rq->nr_queued--; if (!curr) __dequeue_entity(cfs_rq, se); @@ -3836,6 +3843,9 @@ static void reweight_entity(struct cfs_r if (se->rel_deadline) se->deadline =3D div_s64(se->deadline * se->load.weight, weight); =20 + if (rel_vprot) + vprot =3D div_s64(vprot * se->load.weight, weight); + update_load_set(&se->load, weight); =20 do { @@ -3847,6 +3857,8 @@ static void reweight_entity(struct cfs_r enqueue_load_avg(cfs_rq, se); if (se->on_rq) { place_entity(cfs_rq, se, 0); + if (rel_vprot) + se->vprot =3D se->vruntime + vprot; update_load_add(&cfs_rq->load, se->load.weight); if (!curr) __enqueue_entity(cfs_rq, se);