From mboxrd@z Thu Jan 1 00:00:00 1970 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 D63B72367DF for ; Wed, 22 Apr 2026 13:39:23 +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=1776865166; cv=none; b=Mnw9nD833x9bCP57yfyG2h7qPvVN+7aYZu2lXddt23F0Ax4aJeJvr1VaQD/uNqQprwGu2pcUFS+ok0H96j44p0lNGsPl2RJ1aNtUgM4oqaQCyZBTRVL8Pp1g/Xk2b+1HyjuXBzCii5SppcN8UKkVwhAtnkcRFZssUhngiKHR1mY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776865166; c=relaxed/simple; bh=8hxL5hr0natXHRtkQg2Gw5nJWRUEhx8ZidVJiEWmzkU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=npWOFdv1eU9myla4MVh2OhMnfRUVPy48CA3R12oFkxRrebo1VUG9tKq1siwQ3kRN4xu5WC0BVdasGvIkVh1FEIuvBxzWU2kvZxHScZAQbUe6AJmSH9/KEjeel6gOUDzPl0QFCmC8lqw4DDiDFfJyWLMIRUJTlI3F58VX2ayZoq4= 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=snpBCVTr; 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="snpBCVTr" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=HirjE7vl5J2P00boOXIUbPfYbpBumRxAotRNvptpErU=; b=snpBCVTrdo49ZY4B2jgcFisNkq ST3AX0OXRveIFzFdZdO41kU2AKHc5h0A0HN0xIyvE86OIRhTJZIOAnYzvBIWp9N6NpGnql+2YzW51 hmOO+soTbtEg1VBEb8NdumKSSEYzxWhPaHGLFp+zDWPqrkCpDrag8ae1G+rbYw6owi+7Lgsbw+YWo 6BoAyKSA3JaBgElw1rsM5topo7cIHp0P/XmTVMinSNBkKXwlLHgekeugFj0FDWa2N8KF7xE4qzZt2 4i4XzYj8Aj+G2Jnmo8/TN2xEWqZSCCjdwGHk1lYky/44F2PBzhzkY8SNoEnRqAOTF6r1WX7LYu+/B Zwzcq+1w==; 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 casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1wFXnP-0000000Boof-1K1a; Wed, 22 Apr 2026 13:39:15 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id B39D2300BD2; Wed, 22 Apr 2026 15:39:14 +0200 (CEST) Date: Wed, 22 Apr 2026 15:39:14 +0200 From: Peter Zijlstra To: Vincent Guittot Cc: mingo@redhat.com, juri.lelli@redhat.com, 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, shubhang@os.amperecomputing.com Subject: Re: [PATCH v2] sched: fair: Prevent negative lag increase during delayed dequeue Message-ID: <20260422133914.GP3102624@noisy.programming.kicks-ass.net> References: <20260331162352.551501-1-vincent.guittot@linaro.org> <20260402131359.GZ2872@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=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Apr 17, 2026 at 07:18:48PM +0200, Vincent Guittot wrote: > On Thu, 2 Apr 2026 at 15:17, Vincent Guittot wrote: > > On Thu, 2 Apr 2026 at 15:14, Peter Zijlstra wrote: > > > On Tue, Mar 31, 2026 at 06:23:52PM +0200, Vincent Guittot wrote: > > > > +/* > > > > + * Delayed dequeue aims to reduce the negative lag of a dequeued task. > > > > + * While updating the lag of an entity, check that negative lag didn't increase > > > > + * during the delayed dequeue period which would be unfair. > > > > + * Similarly, check that the entity didn't gain positive lag when DELAY_ZERO is > > > > + * set. > > > > + * > > > > + * Return true if the lag has been adjusted. > > > > + */ > > > > +static bool update_entity_lag(struct cfs_rq *cfs_rq, struct sched_entity *se) > > > > { > > > > + s64 vlag; > > > > + > > > > WARN_ON_ONCE(!se->on_rq); > > > > > > > > + vlag = entity_lag(cfs_rq, se, avg_vruntime(cfs_rq)); > > > > + > > > > + if (se->sched_delayed) > > > > + /* previous vlag < 0 otherwise se would not be delayed */ > > > > + se->vlag = clamp(vlag, se->vlag, sched_feat(DELAY_ZERO) ? 0 : S64_MAX); > > > > + else > > > > + se->vlag = vlag; > > > > + > > > > + return (vlag != se->vlag); > > > > } > > > --- a/kernel/sched/fair.c > > > +++ b/kernel/sched/fair.c > > > @@ -841,29 +841,32 @@ static s64 entity_lag(struct cfs_rq *cfs > > > } > > > > > > /* > > > + * Delayed dequeue aims to reduce the negative lag of a dequeued task. While > > > + * updating the lag of an entity, check that negative lag didn't increase > > > * during the delayed dequeue period which would be unfair. > > > + * Similarly, check that the entity didn't gain positive lag when DELAY_ZERO > > > + * is set. > > > * > > > * Return true if the lag has been adjusted. > > > */ > > > +static __always_inline > > > +bool update_entity_lag(struct cfs_rq *cfs_rq, struct sched_entity *se) > > > { > > > + s64 vlag = entity_lag(cfs_rq, se, avg_vruntime(cfs_rq)); > > > + bool ret; > > > > > > WARN_ON_ONCE(!se->on_rq); > > > > > > + if (se->sched_delayed) { > > > /* previous vlag < 0 otherwise se would not be delayed */ > > > + vlag = max(vlag, se->vlag); > > > + if (sched_feat(DELAY_ZERO)) > > > + vlag = min(vlag, 0); > > > + } > > > + ret = (vlag == se->vlag); > > hmm, I missed that we now return false when the lag has been updated > instead of true > > I sent a fix > https://lore.kernel.org/all/20260417171642.3539914-1-vincent.guittot@linaro.org/ D'oh. That said, on IRQ you mentioned that this wasn't quite good enough and that your original patch is best. The trouble is, your original patch can update vlag (!se->sched_delayed) and report it hasn't changed; because then vlag == se->clag, obviously. This invalidates the comment on the return value of the function. In fact, it makes the function have a very non-obvious return meaning. So I'm a little confused -- what do we actually want this function to do? > > > + se->vlag = vlag; > > > > > > + return ret; > > > } > > > > > > /* > > >