All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Guittot <vincent.guittot@linaro.org>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Phil Auld <pauld@redhat.com>,
	Peter Puhov <peter.puhov@linaro.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Robert Foley <robert.foley@linaro.org>,
	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>,
	Jirka Hladky <jhladky@redhat.com>
Subject: Re: [PATCH v1] sched/fair: update_pick_idlest() Select group with lowest group_util when idle_cpus are equal
Date: Fri, 6 Nov 2020 17:06:59 +0100	[thread overview]
Message-ID: <CAKfTPtCzN934zZ5LzP0pv9iMocwjqoH17a=J5RS0OjT9GMFRMw@mail.gmail.com> (raw)
In-Reply-To: <20201106160010.GF3371@techsingularity.net>

On Fri, 6 Nov 2020 at 17:00, Mel Gorman <mgorman@techsingularity.net> wrote:
>
> On Fri, Nov 06, 2020 at 02:33:56PM +0100, Vincent Guittot wrote:
> > On Fri, 6 Nov 2020 at 13:03, Mel Gorman <mgorman@techsingularity.net> wrote:
> > >
> > > On Wed, Nov 04, 2020 at 09:42:05AM +0000, Mel Gorman wrote:
> > > > While it's possible that some other factor masked the impact of the patch,
> > > > the fact it's neutral for two workloads in 5.10-rc2 is suspicious as it
> > > > indicates that if the patch was implemented against 5.10-rc2, it would
> > > > likely not have been merged. I've queued the tests on the remaining
> > > > machines to see if something more conclusive falls out.
> > > >
> > >
> > > It's not as conclusive as I would like. fork_test generally benefits
> > > across the board but I do not put much weight in that.
> > >
> > > Otherwise, it's workload and machine-specific.
> > >
> > > schbench: (wakeup latency sensitive), all machines benefitted from the
> > >         revert at the low utilisation except one 2-socket haswell machine
> > >         which showed higher variability when the machine was fully
> > >         utilised.
> >
> > There is a pending patch to should improve this bench:
> > https://lore.kernel.org/patchwork/patch/1330614/
> >
>
> Ok, I've slotted this one in with a bunch of other stuff I wanted to run
> over the weekend. That particular patch was on my radar anyway. It just
> got bumped up the schedule a little bit.
>
> > > hackbench: Neutral except for the same 2-socket Haswell machine which
> > >         took an 8% performance penalty of 8% for smaller number of groups
> > >         and 4% for higher number of groups.
> > >
> > > pipetest: Mostly neutral except for the *same* machine showing an 18%
> > >         performance gain by reverting.
> > >
> > > kernbench: Shows small gains at low job counts across the board -- 0.84%
> > >         lowest gain up to 5.93% depending on the machine
> > >
> > > gitsource: low utilisation execution of the git test suite. This was
> > >         mostly a win for the revert. For the list of machines tested it was
> > >
> > >          14.48% gain (2 socket but SNC enabled to 4 NUMA nodes)
> > >         neutral      (2 socket broadwell)
> > >         36.37% gain  (1 socket skylake machine)
> > >          3.18% gain  (2 socket broadwell)
> > >          4.4%        (2 socket EPYC 2)
> > >          1.85% gain  (2 socket EPYC 1)
> > >
> > > While it was clear-cut for 5.9, it's less clear-cut for 5.10-rc2 although
> > > the gitsource shows some severe differences depending on the machine that
> > > is worth being extremely cautious about. I would still prefer a revert
> > > but I'm also extremely biased and I know there are other patches in the
> >
> > This one from Julia can also impact
> >
>
> Which one? I'm guessing "[PATCH v2] sched/fair: check for idle core"

Yes, Sorry I sent my answer before adding the link

>
> --
> Mel Gorman
> SUSE Labs

  reply	other threads:[~2020-11-06 16:07 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-14 12:59 [PATCH v1] sched/fair: update_pick_idlest() Select group with lowest group_util when idle_cpus are equal peter.puhov
2020-07-22  9:12 ` [tip: sched/core] " tip-bot2 for Peter Puhov
2020-11-02 10:50 ` [PATCH v1] " Mel Gorman
2020-11-02 11:06   ` Vincent Guittot
2020-11-02 14:44     ` Phil Auld
2020-11-02 16:52       ` Mel Gorman
2020-11-04  9:42       ` Mel Gorman
2020-11-04 10:06         ` Vincent Guittot
2020-11-04 10:47           ` Mel Gorman
2020-11-04 11:34             ` Vincent Guittot
2020-11-06 12:03         ` Mel Gorman
2020-11-06 13:33           ` Vincent Guittot
2020-11-06 16:00             ` Mel Gorman
2020-11-06 16:06               ` Vincent Guittot [this message]
2020-11-06 17:02                 ` Mel Gorman
2020-11-09 15:24               ` Phil Auld
2020-11-09 15:38                 ` Mel Gorman
2020-11-09 15:47                   ` Phil Auld
2020-11-09 15:49                   ` Vincent Guittot
2020-11-10 14:05                     ` Mel Gorman

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='CAKfTPtCzN934zZ5LzP0pv9iMocwjqoH17a=J5RS0OjT9GMFRMw@mail.gmail.com' \
    --to=vincent.guittot@linaro.org \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=jhladky@redhat.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@redhat.com \
    --cc=pauld@redhat.com \
    --cc=peter.puhov@linaro.org \
    --cc=peterz@infradead.org \
    --cc=robert.foley@linaro.org \
    --cc=rostedt@goodmis.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 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.