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

[Roman Gushchin]

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@xxxxxxxxxxxxx>

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!