All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Guittot <vincent.guittot@linaro.org>
To: "Holger Hoffstätte" <holger@applied-asynchrony.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>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	kernel test robot <rong.a.chen@intel.com>,
	Valentin Schneider <valentin.schneider@arm.com>,
	Phil Auld <pauld@redhat.com>, Hillf Danton <hdanton@sina.com>
Subject: Re: [PATCH] sched/cfs: change initial value of runnable_avg
Date: Thu, 25 Jun 2020 11:56:32 +0200	[thread overview]
Message-ID: <CAKfTPtD4+gUkz7Z2o9yyuK09M0bmP=Y+pZTYswNt=yVC4WVkyQ@mail.gmail.com> (raw)
In-Reply-To: <7f2b3135-328b-a510-ce23-49e3f5c20965@applied-asynchrony.com>

On Thu, 25 Jun 2020 at 11:24, Holger Hoffstätte
<holger@applied-asynchrony.com> wrote:
>
> On 2020-06-24 17:44, Vincent Guittot wrote:
> > Some performance regression on reaim benchmark have been raised with
> >    commit 070f5e860ee2 ("sched/fair: Take into account runnable_avg to classify group")
> >
> > The problem comes from the init value of runnable_avg which is initialized
> > with max value. This can be a problem if the newly forked task is finally
> > a short task because the group of CPUs is wrongly set to overloaded and
> > tasks are pulled less agressively.
> >
> > Set initial value of runnable_avg equals to util_avg to reflect that there
> > is no waiting time so far.
> >
> > Fixes: 070f5e860ee2 ("sched/fair: Take into account runnable_avg to classify group")
> > Reported-by: kernel test robot <rong.a.chen@intel.com>
> > Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> > ---
> >   kernel/sched/fair.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 0424a0af5f87..45e467bf42fc 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -806,7 +806,7 @@ void post_init_entity_util_avg(struct task_struct *p)
> >               }
> >       }
> >
> > -     sa->runnable_avg = cpu_scale;
> > +     sa->runnable_avg = sa->util_avg;
> >
> >       if (p->sched_class != &fair_sched_class) {
> >               /*
> >
>
> Something is wrong here. I woke up my machine from suspend-to-RAM this morning
> and saw that a completely idle machine had a loadavg of ~7. According to my

Just to make sure: Are you speaking about loadavg that is output by
/proc/loadavg or load_avg which is the PELT load ?
The output of /proc/loadavg hasn't any link with runnable_avg. The 1st
one monitors nr_running at 5 sec interval whereas the other one is a
geometrics series of the weight of runnable tasks with a half time of
32ms

> monitoring system this happened to be the loadavg right before I suspended.
> I've reverted this, rebooted, created a loadavg >0, suspended and after wake up
> loadavg again correctly ranges between 0 and whatever, as expected.

I'm not sure to catch why ~7 is bad compared to correctly ranges
between 0 and whatever. Isn't ~7 part of the whatever ?

Vincent

>
> -h

  reply	other threads:[~2020-06-25  9:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24 15:44 [PATCH] sched/cfs: change initial value of runnable_avg Vincent Guittot
2020-06-24 16:32 ` Valentin Schneider
2020-06-24 16:40   ` Vincent Guittot
2020-06-25  9:24 ` Holger Hoffstätte
2020-06-25  9:56   ` Vincent Guittot [this message]
2020-06-25 10:42     ` Holger Hoffstätte
2020-06-25 12:08       ` Vincent Guittot
2020-06-25 22:03       ` Holger Hoffstätte
2020-06-25 11:53 ` [tip: sched/urgent] " tip-bot2 for 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='CAKfTPtD4+gUkz7Z2o9yyuK09M0bmP=Y+pZTYswNt=yVC4WVkyQ@mail.gmail.com' \
    --to=vincent.guittot@linaro.org \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=hdanton@sina.com \
    --cc=holger@applied-asynchrony.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=pauld@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rong.a.chen@intel.com \
    --cc=rostedt@goodmis.org \
    --cc=valentin.schneider@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.