From: Mel Gorman <mgorman@suse.de>
To: ?????? <yun.wang@linux.alibaba.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched/numa: advanced per-cgroup numa statistic
Date: Fri, 1 Nov 2019 13:35:28 +0000 [thread overview]
Message-ID: <20191101133528.GP28938@suse.de> (raw)
In-Reply-To: <2573b108-7885-5c4f-a0ae-2b245d663250@linux.alibaba.com>
On Fri, Nov 01, 2019 at 07:52:15PM +0800, ?????? wrote:
> > a much higher degree of flexibility on what information is tracked and
> > allow flexibility on
> >
> > So, overall I think this can be done outside the kernel but recognise
> > that it may not be suitable in all cases. If you feel it must be done
> > inside the kernel, split out the patch that adds information on failed
> > page migrations as it stands apart. Put it behind its own kconfig entry
> > that is disabled by default -- do not tie it directly to NUMA balancing
> > because of the data structure changes. When enabled, it should still be
> > disabled by default at runtime and only activated via kernel command line
> > parameter so that the only people who pay the cost are those that take
> > deliberate action to enable it.
>
> Agree, we could have these per-task faults info there, give the possibility
> to implement maybe a practical userland tool,
I'd prefer not because that would still require the space in the locality
array to store the data. I'd also prefer that numa_faults_locality[]
information is not exposed unless this feature is enabled. That information
is subject to change and interpreting it requires knowledge of the
internals of automatic NUMA balancing.
There are just too many corner cases where the information is garbage.
Tasks with a memory policy would never update the counters, short-lived
tasks may not update it, interleaving will give confused information about
locality, the timing of the reads matter because it might be cleared,
the frequency at which they clear is unknown as the frequency is adaptive
-- the list goes on. I find it very very difficult to believe that a
tool based on faults_locality will be able to give anything but the
most superficial help and any sensible decision will require ftrace or
numa_maps to get real information.
> meanwhile have these kernel
> numa data disabled by default, folks who got no tool but want to do easy
> monitoring can just turn on the switch :-)
>
> Will have these in next version:
>
> * separate patch for showing per-task faults info
Please only expose the failed= (or migfailed=) in that patch. Do not
expose numa_faults_locality unless it is explicitly enabled on behalf of
a tool that claims it can sensibly interpret it.
> * new CONFIG for numa stat (disabled by default)
> * dynamical runtime switch for numa stat (disabled by default)
Dynamic runtime enabling will mean that if it's turned on, the information
will be temporarily useless until stats are accumulated. Make sure to
note that in any associated documentation stating a preference to
enabling it with a kernel parameter.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2019-11-01 13:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 3:08 [PATCH] sched/numa: advanced per-cgroup numa statistic 王贇
2019-10-24 3:16 ` 王贇
2019-10-28 13:02 ` Peter Zijlstra
2019-10-29 2:02 ` 王贇
2019-10-29 7:57 ` [PATCH v2] " 王贇
2019-11-01 17:39 ` Michal Koutný
2019-11-02 1:13 ` 王贇
2019-10-30 9:55 ` [PATCH] " Mel Gorman
2019-10-31 3:31 ` 王贇
2019-10-31 13:17 ` Mel Gorman
2019-11-01 1:49 ` 王贇
2019-11-01 9:13 ` Mel Gorman
2019-11-01 11:52 ` 王贇
2019-11-01 13:35 ` Mel Gorman [this message]
2019-11-02 0:45 ` 王贇
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=20191101133528.GP28938@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=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=yun.wang@linux.alibaba.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