[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250709091741.GH1613200@noisy.programming.kicks-ass.net>
Date: Wed, 9 Jul 2025 11:17:41 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: mingo@...hat.com, juri.lelli@...hat.com, dietmar.eggemann@....com,
rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
vschneid@...hat.com, dhaval@...nis.ca, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/6] sched/fair: Fix NO_RUN_TO_PARITY case
On Tue, Jul 08, 2025 at 06:56:26PM +0200, Vincent Guittot wrote:
> static inline void set_protect_slice(struct sched_entity *se)
> {
> - se->vlag = se->deadline;
> + u64 quantum = se->slice;
> +
> + if (!sched_feat(RUN_TO_PARITY))
> + quantum = min(quantum, normalized_sysctl_sched_base_slice);
> +
> + if (quantum != se->slice)
> + se->vprot = min_vruntime(se->deadline, se->vruntime + calc_delta_fair(quantum, se));
> + else
> + se->vprot = se->deadline;
> }
I've done s/quantum/slice/ on the whole series. In the end this thing:
> +static inline bool resched_next_quantum(struct cfs_rq *cfs_rq, struct sched_entity *curr)
is gone, and *_protect_slice() has slice in the name, and its mostly
assigned from slice named variables.
Final form ends up looking like so:
static inline void set_protect_slice(struct cfs_rq *cfs_rq, struct sched_entity *se)
{
u64 slice = normalized_sysctl_sched_base_slice;
u64 vprot = se->deadline;
if (sched_feat(RUN_TO_PARITY))
slice = cfs_rq_min_slice(cfs_rq);
slice = min(slice, se->slice);
if (slice != se->slice)
vprot = min_vruntime(vprot, se->vruntime + calc_delta_fair(slice, se));
se->vprot = vprot;
}
I'll run a few compiles and then push out to queue/sched/core (and stick
the ttwu bits in queue/sched/ttwu -- as I should've done earlier).
Powered by blists - more mailing lists