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 A953842981C for ; Tue, 16 Jun 2026 10:58:03 +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=1781607488; cv=none; b=job8isslsggkHbtz3Odi5DFlxuQ7GzTJrOgI61b07Ip4OfvmSG8fokKqgrizQff/5+yhBV21jUnZMNGjTZm0mh5Uzx2JdR/IIkSslharKfMOn4xkli9yiVQIhpIFm8BJPjDarkqribbUT843HP2gUzh35y8HhgvHzsYQzYued6E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781607488; c=relaxed/simple; bh=E1kcANndLgNXWMzSQJAZgxcyAify6c2xKjXLrfQwu0Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=V23mhOkRIgnz8T0StcTTSUt5i9lCNnLofpyWj0CHFKLDt+HyHUcb+/psNGOoxLw/RxI8kjunii5mxiOzBGcJy06yhElPEmQ0y4OAPyeivQLxFdmrieXbswbG5H00yc6fTBuJs9RFD7PSrAccgm3/FItW8c1sujSG6NdqjdbW0Q4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=I0JW/X1c; 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=pass 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="I0JW/X1c" 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=MTrXpGKiA3szAdI0ay9fyVcnRU1eDDsZl6Elm6Rs0Zg=; b=I0JW/X1c1Dh7yGQ5CyCv5RaaZp h1K15lwu7pHUKZ7R6G+3xLzs/QybYd0UVOn6gQ7ERmIRqZ8ZWVvq40P8QcsiRMWeEUb1PddAW5x5h NZqRiAVsvnkgtEniACONpgDIlOY5kMpL+fpq1eNiD+PKMW17WuZzjAZRcRQWQIkaB5aRfxdW9bztW /E61LKnywdpryQJaISZzzjgUEvvqufz7xguKe/0qPsMB+R1oyVZGHVWJCd8sZGyGzZuKdWnAVP2SK rxF6rtmcSx4ENok3t8Nc1/TkEDvlpGYXLqSay53xBO3wjnvfc0e8vg46mwgfCHy9oVOJtqdin9XuM 1+tPkKRw==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.99.2 #2 (Red Hat Linux)) id 1wZRUP-0000000AmLd-1TOc; Tue, 16 Jun 2026 10:57:53 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id E24D130031E; Tue, 16 Jun 2026 12:57:51 +0200 (CEST) Date: Tue, 16 Jun 2026 12:57:51 +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, qyousef@layalina.io Subject: Re: [PATCH 6/6 v2] sched/eevdf: Speedup short slice task scheduling Message-ID: <20260616105751.GK42921@noisy.programming.kicks-ass.net> References: <20260615162420.420957-1-vincent.guittot@linaro.org> <20260615162420.420957-7-vincent.guittot@linaro.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: <20260615162420.420957-7-vincent.guittot@linaro.org> On Mon, Jun 15, 2026 at 06:24:20PM +0200, Vincent Guittot wrote: > When a task with a shorter slice is enqueued, we protect the running > task which has a longer slice until it becomes ineligible instead of a > full slice in order to speedup the switch to other tasks until the task > with the shortest slice is scheduled. This helps to the task to not wait > too many full slices before running. > > Signed-off-by: Vincent Guittot > --- > kernel/sched/fair.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 601c67cff185..994fcf3ea702 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -1091,7 +1091,10 @@ static inline void set_protect_slice(struct cfs_rq *cfs_rq, struct sched_entity > slice = cfs_rq_min_slice(cfs_rq); > > slice = min(slice, se->slice); > - if (vruntime != se->vruntime || slice != se->slice) > + > + if (sched_feat(PREEMPT_SHORT) && slice < se->slice) > + vprot = avg_vruntime(cfs_rq); > + else if ((vruntime != se->vruntime) || (slice != se->slice)) > vprot = min_vruntime(vprot, vruntime + calc_delta_fair(slice, se)); > > se->vprot = vprot; I am not entirely sure I understand this one. avg_vruntime() could be ahead of se->deadline, esp for very short slices. This would then extend protection beyond the one slice.. Aside from that, there are but two protect_slice() callers that matter: - pick_eevdf(): this already has a hard limit on avg_vruntime() - update_curr(): this will trigger preemption when reaching either ->deadline or ->vprot. Also, the purpose of vprot is similar to the old min_gran, ensure any task gets *some* time and avoid the degenerate case of endlessly scheduling without 'any' real progress. For EEVDF this happens when tasks get arbitrarily close to avg_vruntime(). Eg, you have the two tasks A,B with A a virtual ns before avg (and per necessity the other 1 ns after). You run A until its just past B, find its not longer eligible, switch to B and do the same. This then results in max frequency context switches and minimal actual progress. The thing that was supposed to stop this is vprot, but if you consistently set vprot at avg_vruntime, this is effectively disabling vprot. No? Now, the conditions for this are such that this only happens for all tasks not of the minimal slice length in the tree. So in order words, you get spikes of high frequency scheduling just to burn vtime in order to achieve eligibility for the earliest min_slice task, right? So what you really want is not avg_vruntime() but the actual se->vruntime of this earliest min_slice entity. Then we can simply run whatever task and not get hit with high frequency scheduling, and still achieve minimal latency for the waiting task. Now, we don't actually have a convenient way to get this specific task, but would something like so work? if (sched_feat(PREEMPT_SHORT) && slice != se->slice) vprot = min_vruntime(vprot, __pick_root_entity(cfs_rq)->vruntime); That is, we protect until the next earliest task becomes eligible. Or did I go off the rails somewhere?