linux-kernel - Re: [PATCH v1 01/12] mm: memcontrol: prepare objcg API for non-kmem usage

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: <YRx4EM0MWSjtutPD@carbon.dhcp.thefacebook.com>
Date:   Tue, 17 Aug 2021 20:01:36 -0700
From:   Roman Gushchin <guro@...com>
To:     Muchun Song <songmuchun@...edance.com>
CC:     <hannes@...xchg.org>, <mhocko@...nel.org>,
        <akpm@...ux-foundation.org>, <shakeelb@...gle.com>,
        <vdavydov.dev@...il.com>, <linux-kernel@...r.kernel.org>,
        <linux-mm@...ck.org>, <duanxiongchun@...edance.com>,
        <fam.zheng@...edance.com>, <bsingharora@...il.com>,
        <shy828301@...il.com>, <alexs@...nel.org>, <smuchun@...il.com>,
        <zhengqi.arch@...edance.com>
Subject: Re: [PATCH v1 01/12] mm: memcontrol: prepare objcg API for non-kmem
 usage

On Sat, Aug 14, 2021 at 01:25:08PM +0800, Muchun Song wrote:
> Pagecache pages are charged at the allocation time and holding a
> reference to the original memory cgroup until being reclaimed.
> Depending on the memory pressure, specific patterns of the page
> sharing between different cgroups and the cgroup creation and
> destruction rates, a large number of dying memory cgroups can be
> pinned by pagecache pages. It makes the page reclaim less efficient
> and wastes memory.
> 
> We can convert LRU pages and most other raw memcg pins to the objcg
> direction to fix this problem, and then the page->memcg will always
> point to an object cgroup pointer.
> 
> Therefore, the infrastructure of objcg no longer only serves
> CONFIG_MEMCG_KMEM. In this patch, we move the infrastructure of the
> objcg out of the scope of the CONFIG_MEMCG_KMEM so that the LRU pages
> can reuse it to charge pages.
> 
> We know that the LRU pages are not accounted at the root level. But
> the page->memcg_data points to the root_mem_cgroup. So the
> page->memcg_data of the LRU pages always points to a valid pointer.
> But the root_mem_cgroup dose not have an object cgroup. If we use
> obj_cgroup APIs to charge the LRU pages, we should set the
> page->memcg_data to a root object cgroup. So we also allocate an
> object cgroup for the root_mem_cgroup.
> 
> Signed-off-by: Muchun Song <songmuchun@...edance.com>

I like the "move objcg stuff to memcg/css level" part.

I'm less convinced about making byte-sized charging kmem-specific
(both naming and #ifdef CONFIG_MEMCG_KMEM). Do we really win a lot?

I understand why we might wanna compile out some checks from the
hot allocation path, but few bytes in struct objcg will not make a big
difference, as well as few lines of code in cgroup creation/removal paths.

Also it might be useful for byte-sized accounting outside kmem, e.g. zswap.
So, I'd remove this dependency and rename to something like
obj_cgroup_release_bytes().

In the long run we might wanna to eliminate CONFIG_MEMCG_KMEM completely,
so let's at least not add new dependencies.

Thanks!