linux-kernel - Re: [PATCH v2 3/5] mm: memcg: merge multiple page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7bm2a2bwwq3jfmdazu23tie3uajvkfzfsrmaeujv4maz4cxvt7@sdth2ybkn4k3>
Date: Wed, 24 Jul 2024 16:43:39 -0700
From: Shakeel Butt <shakeel.butt@...ux.dev>
To: Roman Gushchin <roman.gushchin@...ux.dev>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org, Johannes Weiner <hannes@...xchg.org>, 
	Michal Hocko <mhocko@...nel.org>, Muchun Song <muchun.song@...ux.dev>
Subject: Re: [PATCH v2 3/5] mm: memcg: merge multiple page_counters into a
 single structure

On Wed, Jul 24, 2024 at 08:21:01PM GMT, Roman Gushchin wrote:
> Struct page_counter is used by memory and hugetlb cgroups to track
> the resource usage. Memory cgroups are using up to four different
> counters (on cgroup v1). Hugetlb cgroups are using 2 * HUGE_MAX_HSTATE
> counters.
> 
> Every page_counter structure (except the one belonging to the root
> cgroup) contains a pointer to the corresponding parent structure.
> It's obviously wasteful because for each cgroup there are several
> similar chains of page_counter structures. It's not particularly
> cache-effective too.
> 
> Also every page_counter structure contains fields required for
> tracking the usage of the memory protection, while it's used only
> for the main ("memory") counter and only by memory cgroups.
> 
> To address these issues let's make page_counter structures to support
> N counters and use a single page_counter structure for a memory cgroup
> and 2 page_counter structures for a hugetlb cgroup (to track the
> actual usage and reservations).
> 
> N is determined at the compile time depending on the configuration and
> HUGE_MAX_HSTATE value. HUGE_MAX_HSTATE is relatively small on all
> existing platforms (max is 5 on sparc), so it's not too far from 4
> memcg memory types.
> 
> Memory min/low functionality is supported only for the first counter.
> 
> Memory savings (on x86_64):
> 
> |-----------------------------+----------------------------+----------------------------|
> |                             | memcg                      | hugetlb                    |
> |-----------------------------+----------------------------+----------------------------|
> | original, CONFIG_MEMCG_V1=n | size: 1600, cachelines: 25 | size: 1280, cachelines: 20 |
> | patched, CONFIG_MEMCG_V1=n  | size: 1472, cachelines: 23 | size: 1024, cachelines: 16 |
> |-----------------------------+----------------------------+----------------------------|
> | original, CONFIG_MEMCG_V1=y | size: 2176, cachelines: 34 | size: 1280, cachelines: 20 |
> | patched, CONFIG_MEMCG_V1=y  | size: 1664, cachelines: 26 | size: 1152, cachelines: 18 |
> |-----------------------------+----------------------------+----------------------------|
> 
> So it's 10-35% reduction in the number of cache lines depending on
> the kernel configuration.
> 
> Signed-off-by: Roman Gushchin <roman.gushchin@...ux.dev>

Acked-by: Shakeel Butt <shakeel.butt@...ux.dev>