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 BECA9367F38 for ; Thu, 5 Feb 2026 08:38:32 +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=1770280714; cv=none; b=uLsoI6SzBrOC1/GS7F5vFDoX+jlGWqU0wngK+zJ7n4JkKJOlaB9cGVYMJrcVOlC4Dbq3ygjbghe/dbqE+FfMGBDjfwFVO53LqOLmBQxVp3ZifcAn3LCTxG+z0Epfld1azdFsPqqAIxTzdcYar6AbtZQL39/fs4cDYCH23yueTe8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770280714; c=relaxed/simple; bh=R70TeP332tM8XO28zDr+Z5o3jGq6gGm7NREaxCihcBE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OXzBbW+ahRYAvA8OcaHFrF1mQ3Mlkg3UIZSR2sJ1iEY3JkpRHozpvx+uF1yoI/TxnqoyRzzwPhJNZfleqNpxb8/UQZ0BT0d9+/y49Xi/KxLGKWfnkwCkg+KCC4ytw1m31euDud2jeQ2yEnzv/iVougB2eTCNrD3ZwZc9pKbElQo= 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=DvtNWEvv; 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="DvtNWEvv" 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=wJJR16uNxHxgyLi9gTcluH1zdU6RRB0orwCKS4ZdFMY=; b=DvtNWEvveInkpIB3njgObCYXk4 0LPI6vUKvJCj1+Ntg6Lxy7ZlBBzBDjpJwYShRXKfn6omN55zuXY+utpoICxYSs59cZPIla2SGfBRO L0fdXlNn442SmOPM/D3BmxTaJGLZvENMbN17kC6Fi5YQZ5gxotxg9P7KwV8cxdYhmTxsXAwhApmCV INwlaDeNy4VQnuSfeHSQRSV3SF9xXWVgEnrTeQbINqnk8T9eN9RgOYmBCxGOcSgxRb2QfTHj7qzZF vcSWX/OkxAlwm2xzUgeYbIghTUVcoCsvL+ciXLXekOIFaKlD23Qi3bWxDIZeqd3MnBO0Er8jGZzt3 +DvkU1+Q==; 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 1vnusT-00000003Ljn-2Nbe; Thu, 05 Feb 2026 08:38:17 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 07696300BD2; Thu, 05 Feb 2026 09:38:17 +0100 (CET) Date: Thu, 5 Feb 2026 09:38:16 +0100 From: Peter Zijlstra To: tglx@linutronix.de Cc: arnd@arndb.de, anna-maria@linutronix.de, frederic@kernel.org, luto@kernel.org, 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, linux-kernel@vger.kernel.org, oliver.sang@intel.com Subject: Re: [PATCH v2 1/6] sched/eevdf: Fix HRTICK duration Message-ID: <20260205083816.GB232055@noisy.programming.kicks-ass.net> References: <20260121162010.647043073@infradead.org> <20260121162507.525037175@infradead.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: <20260121162507.525037175@infradead.org> On Wed, Jan 21, 2026 at 05:20:11PM +0100, Peter Zijlstra wrote: > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -6735,21 +6724,39 @@ static inline void sched_fair_update_sto > static void hrtick_start_fair(struct rq *rq, struct task_struct *p) > { > struct sched_entity *se = &p->se; > + unsigned long scale = 1024; > + unsigned long util = 0; > + u64 vdelta; > + u64 delta; > > WARN_ON_ONCE(task_rq(p) != rq); > > + if (rq->cfs.h_nr_queued <= 1) > + return; > + > + /* > + * Compute time until virtual deadline > + */ > + vdelta = se->deadline - se->vruntime; > + if ((s64)vdelta < 0) { > + if (task_current_donor(rq, p)) > + resched_curr(rq); > + return; > + } > + delta = (se->load.weight * vdelta) / NICE_0_LOAD; > + > + /* > + * Correct for instantaneous load of other classes. > + */ > + util += cpu_util_dl(rq); > + util += cpu_util_rt(rq); Since this is all about current, other scheduling classes are irrelevant, they cannot run without causing schedule() which will cause the hrtick to be reprogrammed anyway. So I'm thinking those two lines above ought to go. > + util += cpu_util_irq(rq); > + if (util && util < 1024) { > + scale *= 1024; > + scale /= (1024 - util); > } > + > + hrtick_start(rq, (scale * delta) / 1024); > } > > /* > @@ -5511,7 +5511,7 @@ static void put_prev_entity(struct cfs_r > } > > static void > -entity_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr, int queued) > +entity_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr) > { > /* > * Update run-time statistics of the 'current'. > @@ -5523,17 +5523,6 @@ entity_tick(struct cfs_rq *cfs_rq, struc > */ > update_load_avg(cfs_rq, curr, UPDATE_TG); > update_cfs_group(curr); > - > -#ifdef CONFIG_SCHED_HRTICK > - /* > - * queued ticks are scheduled to match the slice, so don't bother > - * validating it and just reschedule. > - */ > - if (queued) { > - resched_curr_lazy(rq_of(cfs_rq)); > - return; > - } > -#endif > } > > > @@ -13373,7 +13380,7 @@ static void task_tick_fair(struct rq *rq > > for_each_sched_entity(se) { > cfs_rq = cfs_rq_of(se); > - entity_tick(cfs_rq, se, queued); > + entity_tick(cfs_rq, se); > } > > if (queued) { > So Thomas did observe some really small hrtimer reprogramming because of this. If we just miss the normal deadline, it will re-try with a stupid sliver of time. Perhaps it makes sense to leave these two hunks, and simply hard preempt when the hrtick goes, irrespective of slightly missing the vruntime due to the approximation on task-clock.