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

[çè]

Hi, Jonathan

On 2019/11/13 äå11:09, Jonathan Corbet wrote:
> On Wed, 13 Nov 2019 11:45:59 +0800
> çè <yun.wang@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx>
>> Cc: Michal Koutnà <mkoutny@xxxxxxxx>
>> Cc: Mel Gorman <mgorman@xxxxxxx>
>> Signed-off-by: Michael Wang <yun.wang@xxxxxxxxxxxxxxxxx>
>> ---
>>  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
>