mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kayra Cizmeci <kayracizmeci@gmail.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	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,
	jakub@okonski.org, longman@redhat.com, tj@kernel.org,
	 hannes@cmpxchg.org, mkoutny@suse.com, cgroups@vger.kernel.org,
	jstultz@google.com,  qyousef@layalina.io
Subject: Re: [PATCH v2] sched/eevdf: Fix sched idle task group preemption
Date: Wed, 21 Oct 2026 16:41:52 +0300	[thread overview]
Message-ID: <ati_o5c-SoiOp529@scheduler.schedules> (raw)
In-Reply-To: <CAKfTPtDOZ0=nrQe1-WSTamgU0qqdJVvD3KZPtnsqwwnE53BSKA@mail.gmail.com>

On Wed, Oct 21, 2026 at 03:32:59PM +0200, Vincent Guittot wrote:
> On Wed, 21 Oct 2026 at 15:13, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Mon, Oct 19, 2026 at 08:26:22PM +0200, Vincent Guittot wrote:
> > > Even with flat hierarchy which puts all runnable tasks in the same cfs rq,
> > > we need to parse the hierarchy to check for sched_idle task group.
> >
> > I F'ing hate cgroups :-(
> >
> >
> > > +static void
> > > +find_matching_se(struct sched_entity **se, struct sched_entity **pse)
> > > +{
> > > +     int se_depth, pse_depth;
> > > +
> > > +     /*
> > > +      * preemption test can be made between sibling entities who are in the
> > > +      * same cfs_rq i.e who have a common parent. Walk up the hierarchy of
> > > +      * both tasks until we find their ancestors who are siblings of common
> > > +      * parent.
> > > +      */
> > > +
> > > +     /* First walk up until both entities are at same depth */
> > > +     se_depth = (*se)->depth;
> > > +     pse_depth = (*pse)->depth;
> > > +
> > > +     while (se_depth > pse_depth) {
> > > +             se_depth--;
> > > +             *se = parent_entity(*se);
> > > +     }
> > > +
> > > +     while (pse_depth > se_depth) {
> > > +             pse_depth--;
> > > +             *pse = parent_entity(*pse);
> > > +     }
> > > +
> > > +     while (!is_same_group(*se, *pse)) {
> > > +             *se = parent_entity(*se);
> > > +             *pse = parent_entity(*pse);
> > > +     }
> > > +}
> > > +
> > >  static int tg_is_idle(struct task_group *tg)
> > >  {
> > >       return tg->idle > 0;
> > > @@ -476,6 +508,11 @@ static inline struct sched_entity *parent_entity(struct sched_entity *se)
> > >       return NULL;
> > >  }
> > >
> > > +static inline void
> > > +find_matching_se(struct sched_entity **se, struct sched_entity **pse)
> > > +{
> > > +}
> > > +
> > >  static inline int tg_is_idle(struct task_group *tg)
> > >  {
> > >       return 0;
> > > @@ -10129,7 +10166,35 @@ preempt_sync(struct rq *rq, int wake_flags,
> > >  }
> > >
> > >  /*
> > > - * Preempt the current task with a newly woken task if needed:
> > > + * Preempt an idle entity in favor of a non-idle entity (and don't preempt
> > > + * in the inverse case).
> > > + */
> > > +static inline enum preempt_wakeup_action
> > > +wakeup_preempt_sched_idle(struct sched_entity *cse, struct sched_entity *pse)
> > > +{
> > > +     int cse_is_idle, pse_is_idle;
> > > +
> > > +     find_matching_se(&cse, &pse);
> > > +     WARN_ON_ONCE(!pse);
> > > +
> > > +     cse_is_idle = se_is_idle(cse);
> > > +     pse_is_idle = se_is_idle(pse);
> > > +
> > > +     /*
> > > +      * Preempt an idle entity in favor of a non-idle entity (and don't preempt
> > > +      * in the inverse case).
> > > +      */
> > > +     if (cse_is_idle && !pse_is_idle)
> > > +             return PREEMPT_WAKEUP_RESCHED;
> > > +
> > > +     if (cse_is_idle != pse_is_idle)
> > > +             return PREEMPT_WAKEUP_NONE;
> > > +
> > > +     return PREEMPT_WAKEUP_PICK;
> > > +}
> > > +
> > > +/*
> > > + * Preempt the current task with a newly woken task if needed.
> > >   */
> > >  static void wakeup_preempt_fair(struct rq *rq, struct task_struct *p, int wake_flags)
> > >  {
> > > @@ -10137,7 +10202,6 @@ static void wakeup_preempt_fair(struct rq *rq, struct task_struct *p, int wake_f
> > >       struct task_struct *donor = rq->donor;
> > >       struct sched_entity *nse, *se = &donor->se, *pse = &p->se;
> > >       struct cfs_rq *cfs_rq = &rq->cfs;
> > > -     int cse_is_idle, pse_is_idle;
> > >
> > >       /*
> > >        * XXX Getting preempted by higher class, try and find idle CPU?
> > > @@ -10174,22 +10238,14 @@ static void wakeup_preempt_fair(struct rq *rq, struct task_struct *p, int wake_f
> > >       if (!sched_feat(WAKEUP_PREEMPTION))
> > >               return;
> > >
> > > -     WARN_ON_ONCE(!pse);
> > > -
> > > -     cse_is_idle = se_is_idle(se);
> > > -     pse_is_idle = se_is_idle(pse);
> > > +     preempt_action = wakeup_preempt_sched_idle(se, pse);
> > >
> > > -     nse = se;
> > > -     /*
> > > -      * Preempt an idle entity in favor of a non-idle entity (and don't preempt
> > > -      * in the inverse case).
> > > -      */
> > > -     if (cse_is_idle && !pse_is_idle)
> > > +     if (preempt_action == PREEMPT_WAKEUP_RESCHED)
> > >               goto preempt;
> > >
> > >       update_curr_fair(rq);
> > >
> > > -     if (cse_is_idle != pse_is_idle)
> > > +     if (preempt_action == PREEMPT_WAKEUP_NONE)
> > >               goto update;
> > >
> > >       /*
> >
> > What is the actual semantics of cpu.idle nonsense? Why do we care about
> > this common ancestor?
> 
> AFAICT, cpu.idle applied to one level and against entities at the same level
>

Yeah. Like on here:

    ROOT
     /\
    /  \
   /    \
  GA    GB
   |    /\
   V   /  \
  TA  GC   GD
      |    |
      V    V
      TB   TC

If GA is idle and GB is not, while GC is idle and were looking to TA and
TB we gotta choose TB. But if we just look to GC and GA we would choose
neither. .idle just applies to one level as Vincent says.

> >
> > Can't we do any of:
> >
> >  - propagate cfs_rq->idle to all child groups in sched_group_set_idle(); or
> >
> >  - have se_is_idle() walk up and report true if any of the ancestors is
> >    idle?
> 
> I'm fine with either way but this will change the behavior.
> 

So is it good or bad to change the behavior in this case? If we don't
want to change it are there any cleaner way? Well I can't find any.

> >
> > I despise this find_matching_se() thing and was so very glad to have
> > deleted it.
> 
> +1
> 
> >

  reply	other threads:[~2026-10-21 13:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19 18:26 Vincent Guittot
2026-10-21  7:19 ` Kayra Cizmeci
2026-10-21 13:13 ` Peter Zijlstra
2026-10-21 13:32   ` Vincent Guittot
2026-10-21 13:41     ` Kayra Cizmeci [this message]
2026-10-21 14:50       ` Peter Zijlstra
2026-10-21 15:18         ` Kayra Cizmeci
2026-10-21 16:39         ` Josh Don
2026-10-22 11:47           ` Peter Zijlstra
2026-10-22 14:04             ` Kayra Cizmeci
2026-10-22 17:49             ` Josh Don

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=ati_o5c-SoiOp529@scheduler.schedules \
    --to=kayracizmeci@gmail.com \
    --cc=bsegall@google.com \
    --cc=cgroups@vger.kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=hannes@cmpxchg.org \
    --cc=jakub@okonski.org \
    --cc=jstultz@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=mkoutny@suse.com \
    --cc=peterz@infradead.org \
    --cc=qyousef@layalina.io \
    --cc=rostedt@goodmis.org \
    --cc=tj@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    /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®