From: Christian Loehle <christian.loehle@arm.com>
To: Kayra Cizmeci <kayracizmeci@gmail.com>
Cc: dietmar.eggemann@arm.com, elif.topuz@arm.com,
kprateek.nayak@amd.com, linux-kernel@vger.kernel.org,
mingo@redhat.com, peterz@infradead.org, sh@gentwo.org,
vincent.guittot@linaro.org
Subject: Re: [PATCH v2 4/5] sched/eevdf: Keep expired protection expired across reweighting
Date: Thu, 1 Oct 2026 22:51:59 +0100 [thread overview]
Message-ID: <ac4671ff-18a7-4447-84e6-30d35df1c7af@arm.com> (raw)
In-Reply-To: <20261001164609.244156-1-kayracizmeci@gmail.com>
On 10/1/26 17:46, Kayra Cizmeci wrote:
> Sorry for being a bit late :-(
>
>> @@ -4941,6 +4941,9 @@ static void reweight_eevdf(struct cfs_rq *cfs_rq, struct sched_entity *se,
>> se->deadline += avruntime;
>> se->rel_deadline = 0;
>> se->vruntime = avruntime - se->vlag;
>> + /* Reweighting must not revive expired slice protection. */
>> + if (curr && !rel_vprot)
>> + se->vprot = se->vruntime;
>>
>> if (!curr)
> __enqueue_entity(cfs_rq, se);
>> @@ -8204,7 +8207,7 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags)
>> struct sched_entity *se = &p->se;
>> struct cfs_rq *cfs_rq = &rq->cfs;
>> unsigned long weight;
>> - bool curr;
>> + bool curr, expired = false;
>>
>> if (task_is_throttled(p) && enqueue_throttled_task(p))
>> return;
>> @@ -8237,6 +8240,8 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags)
>> * XXX comment on the curr thing
>> */
>> curr = (cfs_rq->curr == se);
>> + if (!curr && task_current_donor(rq, p))
>> + expired = !protect_slice(se);
>> if (curr)
>> place_entity(cfs_rq, se, flags);
>>
>
>> @@ -8248,6 +8253,8 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags)
>> if (!curr) {
>> reweight_eevdf(cfs_rq, se, weight, false);
>> place_entity(cfs_rq, se, flags | ENQUEUE_QUEUED);
>> + if (expired)
>> + se->vprot = se->vruntime;
>> __enqueue_entity(cfs_rq, se);
>> }
>>
>> --
>
> There are a few thing here:
>
> This (!curr) branch has been removed from tip sched/core, here: https://patch.msgid.link/20260911155449.1249726-1-kayracizmeci@gmail.com
> So, heads-up.
Duh yeah, and the fixes I needed are also on sched/core by now, so
no more reason for this awkward base.
>
> Also, when we have alive (or live, as y'all call it, I think it's better this way tho :>)
> protection, and (!expired) reweight_eevdf() doesn't enter the on_rq path and
> alive protection is not reweighted. Not tested tho. And I may be getting something wrong.
> This is not about this patch tho.
No, you're correct, do you wanna fold mine into your fix and send that out?
(I think it looks better squashed but feel free to just pick mine up as your 1/2
if you disagree)
With 1/5 and 3+5/5 dropped there's only the refactor remaining and I might
as well send that as standalone.
>
> Your commit says "Commit ff38424030f9 ("sched/eevdf: Update
> se->vprot in reweight_entity()") subsequently handled live protection,
> but left the expired case unchanged." too. So it's gotta change if I'm not missing something.
Correct!
Thanks!
next prev parent reply other threads:[~2026-10-01 21:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-01 13:40 [PATCH v2 0/5] sched/eevdf: Keep slice protection boundaries consistent Christian Loehle
2026-10-01 13:40 ` [PATCH v2 1/5] sched/fair: Take slice protection into account when arming HRTICK Christian Loehle
2026-10-01 13:43 ` Peter Zijlstra
2026-10-01 14:01 ` Christian Loehle
2026-10-01 13:40 ` [PATCH v2 2/5] sched/eevdf: Share the slice protection calculation Christian Loehle
2026-10-01 13:40 ` [PATCH v2 3/5] sched/eevdf: Cap protection when current has the shortest slice Christian Loehle
2026-10-01 13:55 ` Peter Zijlstra
2026-10-01 13:57 ` Christian Loehle
2026-10-01 13:40 ` [PATCH v2 4/5] sched/eevdf: Keep expired protection expired across reweighting Christian Loehle
2026-10-01 16:46 ` Kayra Cizmeci
2026-10-01 21:51 ` Christian Loehle [this message]
2026-10-02 14:57 ` Kayra Cizmeci
2026-10-01 13:40 ` [PATCH v2 5/5] sched/eevdf: Update protection after restoring current Christian Loehle
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=ac4671ff-18a7-4447-84e6-30d35df1c7af@arm.com \
--to=christian.loehle@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=elif.topuz@arm.com \
--cc=kayracizmeci@gmail.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=sh@gentwo.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®