Re: [PATCH v6 0/2] sched/numa: introduce numa locality

[王贇 <yun.wang@linux.alibaba.com>]

Dear folks,

During our testing, we found in some cases the NUMA Balancing
is not helping improving locality, that is the memory writing
inside a virtual machine.

The VM is created by docker kata-runtime, inside guest the
container executed several tasks to malloc memory and keep
writing in page size, then report the time cost after finished
1G writing.

The result is not as good as runc, and we found the locality
is not growing in kata cases, with some debugging we located
the reason.

Those vcpu threads created by VM is rarely exit into userspace
in this case, they just stay in kernel after calling ioctl(KVM_RUN),
while NUMA Balancing work is done with task_work_run(), which
is handled together with signal handling before exit to usermode.

So the situation is, for these vcpu threads, NUMA Balancing work
was queued with task_work_add(), but never got chance to finish.

Now the question is, is this by designed or not?

BTW, we also passed the NUMA topology into VM, but still the result
is not as good as runc, seems like the effect of NUMA Balancing on
host is far more better than inside guest.

Regards,
Michael Wang


On 2019/12/13 上午9:43, 王贇 wrote:
> Since v5:
>   * fix compile failure when NUMA disabled
> Since v4:
>   * improved documentation
> Since v3:
>   * fix comments and improved documentation
> Since v2:
>   * simplified the locality concept & implementation
> Since v1:
>   * improved documentation
> 
> Modern production environment could use hundreds of cgroup to control
> the resources for different workloads, along with the complicated
> resource binding.
> 
> On NUMA platforms where we have multiple nodes, things become even more
> complicated, we hope there are more local memory access to improve the
> performance, and NUMA Balancing keep working hard to achieve that,
> however, wrong memory policy or node binding could easily waste the
> effort, result a lot of remote page accessing.
> 
> We need to notice such problems, then we got chance to fix it before
> there are too much damages, however, there are no good monitoring
> approach yet to help catch the mouse who introduced the remote access.
> 
> This patch set is trying to fill in the missing pieces， by introduce
> the per-cgroup NUMA locality info, with this new statistics, we could
> achieve the daily monitoring on NUMA efficiency, to give warning when
> things going too wrong.
> 
> Please check the second patch for more details.
> 
> Michael Wang (2):
>   sched/numa: introduce per-cgroup NUMA locality info
>   sched/numa: documentation for per-cgroup numa statistics
> 
>  Documentation/admin-guide/cg-numa-stat.rst      | 178 ++++++++++++++++++++++++
>  Documentation/admin-guide/index.rst             |   1 +
>  Documentation/admin-guide/kernel-parameters.txt |   4 +
>  Documentation/admin-guide/sysctl/kernel.rst     |   9 ++
>  include/linux/sched.h                           |  15 ++
>  include/linux/sched/sysctl.h                    |   6 +
>  init/Kconfig                                    |  11 ++
>  kernel/sched/core.c                             |  75 ++++++++++
>  kernel/sched/fair.c                             |  62 +++++++++
>  kernel/sched/sched.h                            |  12 ++
>  kernel/sysctl.c                                 |  11 ++
>  11 files changed, 384 insertions(+)
>  create mode 100644 Documentation/admin-guide/cg-numa-stat.rst
>