From: Christian Loehle <christian.loehle@arm.com>
To: linux-kernel@vger.kernel.org, mingo@redhat.com,
peterz@infradead.org, vincent.guittot@linaro.org
Cc: dietmar.eggemann@arm.com, kayracizmeci@gmail.com,
Elif Topuz <elif.topuz@arm.com>
Subject: Re: [PATCH 1/2] sched/eevdf: Cap protection when current has the shortest slice
Date: Wed, 30 Sep 2026 14:15:19 +0100 [thread overview]
Message-ID: <9ea8703f-ef5a-425b-9d95-dbecacf5238b@arm.com> (raw)
In-Reply-To: <dd46b8eddbd760b4d5f2cb7d0eb5027bf70fad32.1790756779.git.christian.loehle@arm.com>
On 9/30/26 09:47, Christian Loehle wrote:
> Changing a task's slice does not discard its remaining request. With
> PLACE_REL_DEADLINE, the preserved deadline can therefore extend beyond
> the new slice after sched_setattr() reduces it.
>
> set_protect_slice() starts from that deadline and only applies the slice
> cap when another entity has a shorter slice. If current itself has the
> shortest slice, a later pick can protect it for the remainder of the old
> request. update_curr() then need not request another selection when a
> competitor becomes eligible.
>
> For a preserved deadline d beyond the new virtual slice vslice:
>
> v v + vslice d
> |---------------------|----------------------|
> old: |<---------------- protection -------------->|
> new: |<---- protection --->|
>
> Commit aae2a33ea662 ("sched/eevdf: Ensure that vprot will never go above a
> min slice") caps protection even when the ineligibility boundary is later,
> but leaves this slice == se->slice case uncovered.
>
> Apply the minimum-slice cap unconditionally, including when it is
> current's own slice. Keep the earlier ineligibility boundary for the
> PREEMPT_SHORT case when a shorter slice is competing. This preserves the
> outstanding request while limiting protection at each fresh pick.
>
> Fixes: 82e9d0456e06 ("sched/fair: Avoid re-setting virtual deadline on 'migrations'")
> Signed-off-by: Christian Loehle <christian.loehle@arm.com>
> ---
> kernel/sched/fair.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 85bf02570473..868c3911337a 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1128,13 +1128,12 @@ 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);
> + /* A preserved deadline can extend beyond the current slice. */
> + vprot = min_vruntime(vprot, se->vruntime + calc_delta_fair(slice, se));
>
> /* If there are shorter slices than se's one */
> - if (slice != se->slice) {
> - vprot = min_vruntime(vprot, se->vruntime + calc_delta_fair(slice, se));
> - if (sched_feat(PREEMPT_SHORT))
> - vprot = min_vruntime(vprot, ineligible_vruntime(cfs_rq));
> - }
> + if (sched_feat(PREEMPT_SHORT) && slice != se->slice)
> + vprot = min_vruntime(vprot, ineligible_vruntime(cfs_rq));
>
> se->vprot = vprot;
> }
Elif (+CC) made me aware that apart from the slice protection boundary and vruntime, which is:
set_protect_slice(): deadline, se->vruntime
update_protect_slice(): vprot, min(se->vruntime, avg_vruntime())
this now mirrors update_protect_slice() so should probably be merged into one, I'll resend.
next prev parent reply other threads:[~2026-09-30 13:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 8:47 [PATCH 0/2] sched/eevdf: Fix slice protection across state changes Christian Loehle
2026-09-30 8:47 ` [PATCH 1/2] sched/eevdf: Cap protection when current has the shortest slice Christian Loehle
2026-09-30 13:15 ` Christian Loehle [this message]
2026-09-30 8:47 ` [PATCH 2/2] sched/eevdf: Keep expired protection expired across reweighting Christian Loehle
2026-09-30 13:37 ` Kayra Cizmeci
2026-09-30 15:28 ` Christian Loehle
2026-09-30 15:34 ` Kayra Cizmeci
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9ea8703f-ef5a-425b-9d95-dbecacf5238b@arm.com \
--to=christian.loehle@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=elif.topuz@arm.com \
--cc=kayracizmeci@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®