Re: [PATCH 3/3] sched/numa: documentation for per-cgroup numa stat

王贇
2019-11-14T01:52:49Z

Hi, Jonathan

On 2019/11/13 下午11:09, Jonathan Corbet wrote:
> On Wed, 13 Nov 2019 11:45:59 +0800
> 王贇 <yun.wang@linux.alibaba.com> wrote:
>
>> Add the description for 'cg_numa_stat', also a new doc to explain
>> the details on how to deal with the per-cgroup numa statistics.
>>
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Cc: Michal Koutný <mkoutny@suse.com>
>> Cc: Mel Gorman <mgorman@suse.de>
>> Signed-off-by: Michael Wang <yun.wang@linux.alibaba.com>
>> ---
>> Documentation/admin-guide/cg-numa-stat.rst | 161 ++++++++++++++++++++++++
>> Documentation/admin-guide/kernel-parameters.txt | 4 +
>> Documentation/admin-guide/sysctl/kernel.rst | 9 ++
>> 3 files changed, 174 insertions(+)
>> create mode 100644 Documentation/admin-guide/cg-numa-stat.rst
>
> Thanks for adding documentation for your new feature! When you add a new
> RST file, though, you should also add it to index.rst so that it becomes a
> part of the docs build.

Thanks for pointing out :-) will fix this in next version.

>
> A couple of nits below...
>
>> diff --git a/Documentation/admin-guide/cg-numa-stat.rst b/Documentation/admin-guide/cg-numa-stat.rst
>> new file mode 100644
>> index 000000000000..87b716c51e16
>> --- /dev/null
[snip]
>> +For example the 'cpu.numa_stat' show:
>> + locality 39541 60962 36842 72519 118605 721778 946553
>> + exectime 1220127 1458684
>
> You almost certainly want that rendered as a literal block, so say
> "show::". There are other places where you'll want to do that as well.

I see, will fix such cases.

>
>> +The locality is sectioned into 7 regions, closely as:
>> + 0-13% 14-27% 28-42% 43-56% 57-71% 72-85% 86-100%
>> +
>> +And exectime is sectioned into 2 nodes, 0 and 1 in this case.
>> +
>> +Thus we know the workload of this group and it's descendants have totally
>> +executed 1220127ms on node_0 and 1458684ms on node_1, tasks with locality
>> +around 0~13% executed for 39541 ms, and tasks with locality around 87~100%
>> +executed for 946553 ms, which imply most of the memory access are local.
>> +
>> +Monitoring
>> +-----------------
>
> A slightly long underline :)

Aha, will fix this too.

Regards,
Michael Wang

>
> I'll stop here; thanks again for adding documentation.
>
> jon
>