linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vincent Guittot <vincent.guittot@linaro.org>
To: Josh Don <joshdon@google.com>
Cc: Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Benjamin Segall <bsegall@google.com>,
	Mel Gorman <mgorman@suse.de>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	parth@linux.ibm.com, Qais Yousef <qais.yousef@arm.com>,
	"Hyser,Chris" <chris.hyser@oracle.com>,
	Pavan Kondeti <pkondeti@codeaurora.org>,
	Valentin Schneider <Valentin.Schneider@arm.com>,
	patrick.bellasi@matbug.net, David.Laight@aculab.com,
	Paul Turner <pjt@google.com>,
	pavel@ucw.cz, Tejun Heo <tj@kernel.org>,
	Dhaval Giani <dhaval.giani@oracle.com>,
	qperret@google.com, Tim Chen <tim.c.chen@linux.intel.com>
Subject: Re: [RFC 5/6] sched/fair: Take into account latency nice at wakeup
Date: Tue, 15 Mar 2022 14:54:51 +0100	[thread overview]
Message-ID: <CAKfTPtD0kFuyh+Q3po0UHR3GQz1uKGxRrFWDfsHcCuQr4ZWbNQ@mail.gmail.com> (raw)
In-Reply-To: <CABk29Numf595wF6PiLd673TmFt6AV9qTEsWP7tSf2xPOKcGgLQ@mail.gmail.com>

On Tue, 15 Mar 2022 at 01:53, Josh Don <joshdon@google.com> wrote:
>
> Hi Vincent,
>
> On Fri, Mar 11, 2022 at 8:21 AM Vincent Guittot
> <vincent.guittot@linaro.org> wrote:
> >
> [snip]
> > +
> > +static void check_preempt_from_idle(struct cfs_rq *cfs, struct sched_entity *se)
> > +{
> > +       struct sched_entity *next;
> > +
> > +       if (se->latency_weight <= 0)
> > +               return;
> > +
> > +       if (cfs->nr_running <= 1)
> > +               return;
>
> I don't quite understand this nr_running check.

just to return early if there is no other task running on the cfs

>
> > +       /*
> > +        * When waking from idle, we don't need to check to preempt at wakeup
> > +        * the idle thread and don't set next buddy as a candidate for being
> > +        * picked in priority.
> > +        * In case of simultaneous wakeup from idle, the latency sensitive tasks
> > +        * lost opportunity to preempt non sensitive tasks which woke up
> > +        * simultaneously.
> > +        */
> > +
> > +       if (cfs->next)
> > +               next = cfs->next;
> > +       else
> > +               next = __pick_first_entity(cfs);
> > +
> > +       if (next && wakeup_preempt_entity(next, se) == 1)
> > +               set_next_buddy(se);
> > +}
> > +
>
> What's the motivation to do this with the next buddy vs using wakeup
> entity placement to achieve a similar result? The latter would also

I don't want to modify vruntime because of latency prio because it
would mean impacting the cpu bandwidth of the task which is managed
with nice priority. latency nice is only  about preempting current
running task

> more generically work when we aren't transitioning from idle. It also
> doesn't suffer from some slight weirdness here in the interaction with
> core scheduling, where rq->curr can be idle despite the presence of
> runnable tasks if the cpu is forced idle.

TBH, I haven't looked in details the core scheduling part which adds
another level of complexity when selecting which task should run on
the core

  reply	other threads:[~2022-03-15 13:55 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-11 16:14 [PATCH 0/6] Add latency_nice priority Vincent Guittot
2022-03-11 16:14 ` [PATCH 1/6] sched: Introduce latency-nice as a per-task attribute Vincent Guittot
2022-03-11 16:14 ` [PATCH 2/6] sched/core: Propagate parent task's latency requirements to the child task Vincent Guittot
2022-03-22  0:22   ` Tim Chen
2022-03-22 14:57     ` Vincent Guittot
2022-03-11 16:14 ` [PATCH 3/6] sched: Allow sched_{get,set}attr to change latency_nice of the task Vincent Guittot
2022-03-22  0:22   ` Tim Chen
2022-03-22 14:55     ` Vincent Guittot
2022-03-28  9:23   ` Dietmar Eggemann
2022-03-28 12:41     ` Vincent Guittot
2022-03-11 16:14 ` [PATCH 4/6] sched/core: Add permission checks for setting the latency_nice value Vincent Guittot
2022-03-11 16:14 ` [RFC 5/6] sched/fair: Take into account latency nice at wakeup Vincent Guittot
2022-03-15  0:53   ` Josh Don
2022-03-15 13:54     ` Vincent Guittot [this message]
2022-03-28  9:24   ` Dietmar Eggemann
2022-03-28 12:51     ` Vincent Guittot
2022-05-01 15:58   ` Tao Zhou
2022-05-02  9:54     ` Vincent Guittot
2022-05-02 12:30       ` Vincent Guittot
2022-05-02 15:08         ` Tao Zhou
2022-05-02 15:26           ` Tao Zhou
2022-05-02 15:47             ` Tao Zhou
2022-05-02 16:21               ` Vincent Guittot
2022-05-02 23:09                 ` Tao Zhou
2022-05-03  2:30     ` Tao Zhou
2022-05-03 12:40       ` Vincent Guittot
2022-05-04 11:14   ` Chen Yu
2022-05-04 12:39     ` Vincent Guittot
2022-03-11 16:14 ` [RFC 6/6] sched/fair: Add sched group latency support Vincent Guittot
2022-03-15  0:58   ` Josh Don
2022-03-15 17:07     ` Vincent Guittot
2022-03-21 17:24   ` Tejun Heo
2022-03-22 16:10     ` Vincent Guittot
2022-03-22 16:40       ` Tejun Heo
2022-03-23 15:04         ` Vincent Guittot
2022-03-23 18:20           ` Chris Hyser
2022-03-22 16:41     ` Tim Chen
2022-03-23 15:23       ` Vincent Guittot
2022-03-22 16:39 ` [PATCH 0/6] Add latency_nice priority Qais Yousef
2022-03-23 15:32   ` Vincent Guittot
2022-03-24 17:25     ` Qais Yousef
2022-03-25 13:27       ` Vincent Guittot
2022-03-28 16:27         ` Qais Yousef
2022-03-30  7:30           ` Vincent Guittot
2022-03-28  9:24 ` Dietmar Eggemann
2022-03-28 12:56   ` Vincent Guittot
2022-04-01 12:15     ` Qais Yousef
2022-04-02  8:46       ` Vincent Guittot
2022-04-09 17:08         ` Qais Yousef
2022-04-09 17:28           ` Steven Rostedt
2022-04-09 18:10             ` Qais Yousef
2022-04-11  7:26               ` Vincent Guittot

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=CAKfTPtD0kFuyh+Q3po0UHR3GQz1uKGxRrFWDfsHcCuQr4ZWbNQ@mail.gmail.com \
    --to=vincent.guittot@linaro.org \
    --cc=David.Laight@aculab.com \
    --cc=Valentin.Schneider@arm.com \
    --cc=bsegall@google.com \
    --cc=chris.hyser@oracle.com \
    --cc=dhaval.giani@oracle.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=joshdon@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=parth@linux.ibm.com \
    --cc=patrick.bellasi@matbug.net \
    --cc=pavel@ucw.cz \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=pkondeti@codeaurora.org \
    --cc=qais.yousef@arm.com \
    --cc=qperret@google.com \
    --cc=rostedt@goodmis.org \
    --cc=tim.c.chen@linux.intel.com \
    --cc=tj@kernel.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;
as well as URLs for NNTP newsgroup(s).