From: Mel Gorman <mgorman@suse.de>
To: Vincent Guittot <vincent.guittot@linaro.org>
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>,
linux-kernel <linux-kernel@vger.kernel.org>,
Phil Auld <pauld@redhat.com>, Parth Shah <parth@linux.ibm.com>,
Valentin Schneider <valentin.schneider@arm.com>
Subject: Re: [RFC 2/4] sched/numa: replace runnable_load_avg by load_avg
Date: Wed, 12 Feb 2020 16:04:31 +0000 [thread overview]
Message-ID: <20200212160431.GW3420@suse.de> (raw)
In-Reply-To: <CAKfTPtAJE_eDgR8dmScgVbOgS9sQSJg27Mw62Z1htMCmgN_Yew@mail.gmail.com>
On Wed, Feb 12, 2020 at 04:03:28PM +0100, Vincent Guittot wrote:
> > Ok, so this is essentially group_is_overloaded.
> >
> >
> > > + if ((ns->nr_running < ns->weight) ||
> > > + ((ns->compute_capacity * 100) > (ns->util * imbalance_pct)))
> > > + return node_has_spare;
> > > +
> >
> > And this is group_has_capacity. What I did was have a common helper
> > for both NUMA and normal load balancing and translated the fields from
> > sg_lb_stats and numa_stats into a common helper. This is to prevent them
> > getting out of sync. The conversion was incomplete in my case but in
> > principle, both NUMA and CPU load balancing should use common helpers or
> > they'll get out of sync.
>
> I fact, I wanted to keep this patch simple and readable for the 1st
> version in order to not afraid people from reviewing it. That's the
> main reason I didn't merge it with load_balance but i agree that some
> common helper function might be possible.
>
Makes sense.
> Also the struct sg_lb_stats has a lot more fields compared to struct numa_stats
>
Yes, I considered reusing the same structure and decided against it. I
simply created a common helper. It's trivial enough to do on top after
the fact in the name of clarity. Fundamentally it's cosmetic.
> Then, I wonder if we could end up with different rules for numa like
> taking into account some NUMA specifics metrics to classify the node
>
Well, we could but right now they should be the same. As it is, the NUMA
balancer and load balancer overrule each other. I think the scope for
changing that without causing regressions is limited.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2020-02-12 16:04 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-11 17:46 [PATCH 0/4] remove runnable_load_avg and improve group_classify Vincent Guittot
2020-02-11 17:46 ` [PATCH 1/4] sched/fair: reorder enqueue/dequeue_task_fair path Vincent Guittot
2020-02-12 13:20 ` Mel Gorman
2020-02-12 14:47 ` Vincent Guittot
2020-02-12 16:11 ` Mel Gorman
2020-02-11 17:46 ` [RFC 2/4] sched/numa: replace runnable_load_avg by load_avg Vincent Guittot
2020-02-12 13:37 ` Mel Gorman
2020-02-12 15:03 ` Vincent Guittot
2020-02-12 16:04 ` Mel Gorman [this message]
2020-02-12 19:49 ` Mel Gorman
2020-02-12 21:29 ` Mel Gorman
2020-02-13 8:05 ` Vincent Guittot
2020-02-13 9:24 ` Mel Gorman
[not found] ` <20200213131658.9600-1-hdanton@sina.com>
2020-02-13 13:46 ` Mel Gorman
2020-02-13 15:00 ` Phil Auld
2020-02-13 15:14 ` Mel Gorman
2020-02-13 16:11 ` Vincent Guittot
2020-02-13 16:34 ` Mel Gorman
2020-02-13 16:38 ` Vincent Guittot
2020-02-13 17:02 ` Mel Gorman
2020-02-13 17:15 ` Vincent Guittot
2020-02-11 17:46 ` [RFC 3/4] sched/fair: replace runnable load average by runnable average Vincent Guittot
2020-02-12 14:30 ` Mel Gorman
2020-02-14 7:42 ` Vincent Guittot
2020-02-13 17:36 ` Peter Zijlstra
2020-02-14 7:43 ` Vincent Guittot
2020-02-11 17:46 ` [RFC 4/4] sched/fair: Take into runnable_avg to classify group Vincent Guittot
2020-02-13 18:32 ` Valentin Schneider
2020-02-13 18:37 ` Valentin Schneider
2020-02-14 7:48 ` Vincent Guittot
2020-02-11 21:04 ` [PATCH 0/4] remove runnable_load_avg and improve group_classify Mel Gorman
2020-02-12 8:16 ` 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=20200212160431.GW3420@suse.de \
--to=mgorman@suse.de \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=parth@linux.ibm.com \
--cc=pauld@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=valentin.schneider@arm.com \
--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 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.