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 >
