mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.


  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®