On 18 July 2018 at 17:26, Shakeel Butt <shakeelb@xxxxxxxxxx> wrote:
> On Wed, Jul 18, 2018 at 7:29 AM Bruce Merry <bmerry@xxxxxxxxx> wrote:
> It seems like you are using cgroup-v1. How many nodes are there in
> your memcg tree and also how many cpus does the system have?
>From my original email: "there are 106 memory.stat files in
/sys/fs/cgroup/memory." - is that what you mean by the number of
nodes?
The affected systems all have 8 CPU cores (hyperthreading is disabled).
> Please note that memcg_stat_show or reading memory.stat in cgroup-v1
> is not optimized as cgroup-v2. The function memcg_stat_show() in 4.13
> does ~17 tree walks and then for ~12 of those tree walks, it goes
> through all cpus for each node in the memcg tree. In 4.16,
> a983b5ebee57 ("mm: memcontrol: fix excessive complexity in memory.stat
> reporting") optimizes aways the cpu traversal at the expense of some
> accuracy. Next optimization would be to do just one memcg tree
> traversal similar to cgroup-v2's memory_stat_show().
On most machines it is still fast (1-2ms), and there is no difference
in the number of CPUs and only very small differences in the number of
live memory cgroups, so presumably something else is going on.
> The memcg tree does include all zombie memcgs and these zombies does
> contribute to the memcg_stat_show cost.
That sounds promising. Is there any way to tell how many zombies there
are, and is there any way to deliberately create zombies? If I can
produce zombies that might give me a reliable way to reproduce the
problem, which could then sensibly be tested against newer kernel
versions.
Thanks
Bruce
--
Bruce Merry
Senior Science Processing Developer
SKA South Africa
