Message-ID: <9eac8254-2d53-5d09-1394-26438db9a6a9@linux.alibaba.com>
Date:   Sat, 2 Nov 2019 08:45:40 +0800
From:   王贇 <yun.wang@...ux.alibaba.com>
To:     Mel Gorman <mgorman@...e.de>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched/numa: advanced per-cgroup numa statistic



On 2019/11/1 下午9:35, Mel Gorman wrote:
> 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.

Yeah, there are no very good approach to estimate the numa efficiency
since there are no per-task counter to tell the local & remote accessing
on hardware level, numa balancing won't cover all the cases, otherwise
we will have overhead issue again.

Well, at least we will be able to know whether this feature itself is
working well or not by reading locality, especially for cross nodes
workloads, locality could at least tell us the numa balancing is helping,
or just wasting resources :-P

> 
>> 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.

Sounds fair enough, no such tool yet.

> 
>>  * 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.

That's right, will highlight in the doc.

Regards,
Michael Wang

> 

Powered by blists - more mailing lists