[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201209022118.GB2385286@carbon.DHCP.thefacebook.com>
Date: Tue, 8 Dec 2020 18:21:18 -0800
From: Roman Gushchin <guro@...com>
To: Muchun Song <songmuchun@...edance.com>
CC: <hannes@...xchg.org>, <mhocko@...nel.org>,
<vdavydov.dev@...il.com>, <akpm@...ux-foundation.org>,
<shakeelb@...gle.com>, <sfr@...b.auug.org.au>,
<chris@...isdown.name>, <laoar.shao@...il.com>,
<richard.weiyang@...il.com>, <linux-kernel@...r.kernel.org>,
<cgroups@...r.kernel.org>, <linux-mm@...ck.org>
Subject: Re: [PATCH v2] mm: memcontrol: optimize per-lruvec stats counter
memory usage
On Tue, Dec 08, 2020 at 05:51:32PM +0800, Muchun Song wrote:
> The vmstat threshold is 32 (MEMCG_CHARGE_BATCH), so the type of s32
> of lruvec_stat_cpu is enough. And introduce struct per_cpu_lruvec_stat
> to optimize memory usage.
>
> The size of struct lruvec_stat is 304 bytes on 64 bits system. As it
> is a per-cpu structure. So with this patch, we can save 304 / 2 * ncpu
> bytes per-memcg per-node where ncpu is the number of the possible CPU.
> If there are c memory cgroup (include dying cgroup) and n NUMA node in
> the system. Finally, we can save (152 * ncpu * c * n) bytes.
Honestly, I'm not convinced.
Say, ncpu = 32, n = 2, c = 500. We're saving <5Mb of memory.
If the machine has 128Gb of RAM, it's .000000003%.
Using longs (s64) allows not to think too much about overflows
and can also be slightly faster on 64-bit machines.
Thanks!
Powered by blists - more mailing lists