From: Tao Cui <cuitao@kylinos.cn>

The legacy cgroup v1 memory controller has already been moved out of
the shared implementation at the file level (mm/memcontrol-v1.c) and at
the Kconfig level (CONFIG_MEMCG_V1, default n since 6.11).  Its
per-cgroup state, however, still sits as individual members inside
struct mem_cgroup, guarded by #ifdefs.

This series isolates the deprecated implementation from the shared hot
structure: all v1-only members are grouped into a dedicated
struct mem_cgroup_v1, and every access goes through memcg->v1.X.

With this in place the v1 implementation is self-contained: its
interface in mm/memcontrol-v1.c, its state in struct mem_cgroup_v1, and
its eventual removal becomes a localized deletion of this struct
together with mm/memcontrol-v1.c, instead of unwinding
ifdef-scattered members across the shared header.

Patch 1 introduces the substruct behind a transitional union whose
anonymous side preserves the historical layout, so the patch is
semantically empty.  Patch 2 converts the access sites and drops the
anonymous side.  Patch 3 documents the boundary.

This demonstrates one possible pattern for isolating deprecated cgroup
v1 implementation from shared structures.

As a validation detail, this does not regress the layout: the member
order is preserved, so offsetof(struct mem_cgroup, v1.swappiness) and
sizeof(struct mem_cgroup) are unchanged (verified with pahole), and the
generated code of hot paths such as mem_cgroup_swappiness() is
identical.  Build-tested with CONFIG_MEMCG_V1 both enabled and
disabled, and boot-tested with both a v1 and a v2 hierarchy.

Tao Cui (3):
  mm, memcg: introduce struct mem_cgroup_v1
  mm, memcg: move v1-only members into mem_cgroup_v1
  docs: cgroup-v1: note the v1 memory controller implementation boundary

 .../admin-guide/cgroup-v1/memory.rst          |   7 +
 include/linux/memcontrol.h                    |  74 +++++------
 include/net/sock.h                            |   2 +-
 mm/memcontrol-v1.c                            | 122 +++++++++---------
 mm/memcontrol-v1.h                            |   4 +-
 mm/memcontrol.c                               |  22 ++--
 mm/swap.h                                     |   2 +-
 7 files changed, 121 insertions(+), 112 deletions(-)

-- 
2.43.0

On Wed, Sep 16, 2026 at 08:57:34PM +0800, Tao Cui wrote:
> From: Tao Cui <cuitao@kylinos.cn>
> 
> The legacy cgroup v1 memory controller has already been moved out of
> the shared implementation at the file level (mm/memcontrol-v1.c) and at
> the Kconfig level (CONFIG_MEMCG_V1, default n since 6.11).  Its
> per-cgroup state, however, still sits as individual members inside
> struct mem_cgroup, guarded by #ifdefs.
> 
> This series isolates the deprecated implementation from the shared hot
> structure: all v1-only members are grouped into a dedicated
> struct mem_cgroup_v1, and every access goes through memcg->v1.X.
> 
> With this in place the v1 implementation is self-contained: its
> interface in mm/memcontrol-v1.c, its state in struct mem_cgroup_v1, and
> its eventual removal becomes a localized deletion of this struct
> together with mm/memcontrol-v1.c, instead of unwinding
> ifdef-scattered members across the shared header.

Sorry I don't see any benefit of this code churn. The code is already behind
config. What exactly this code churn is giving us?

On Thu 17-09-26 13:26:40, Shakeel Butt wrote:
> On Wed, Sep 16, 2026 at 08:57:34PM +0800, Tao Cui wrote:
> > From: Tao Cui <cuitao@kylinos.cn>
> > 
> > The legacy cgroup v1 memory controller has already been moved out of
> > the shared implementation at the file level (mm/memcontrol-v1.c) and at
> > the Kconfig level (CONFIG_MEMCG_V1, default n since 6.11).  Its
> > per-cgroup state, however, still sits as individual members inside
> > struct mem_cgroup, guarded by #ifdefs.
> > 
> > This series isolates the deprecated implementation from the shared hot
> > structure: all v1-only members are grouped into a dedicated
> > struct mem_cgroup_v1, and every access goes through memcg->v1.X.
> > 
> > With this in place the v1 implementation is self-contained: its
> > interface in mm/memcontrol-v1.c, its state in struct mem_cgroup_v1, and
> > its eventual removal becomes a localized deletion of this struct
> > together with mm/memcontrol-v1.c, instead of unwinding
> > ifdef-scattered members across the shared header.
> 
> Sorry I don't see any benefit of this code churn. The code is already behind
> config. What exactly this code churn is giving us?

The only arguable upside is that this would make it ever so slightly
easier to track v1 specific stuff (once that s@v1@memcg1@ or similar).
I am not convinced this is sufficient to justify the churn either.
-- 
Michal Hocko
SUSE Labs

On Fri, Sep 18, 2026 at 11:41:09AM +0200, Michal Hocko wrote:
> On Thu 17-09-26 13:26:40, Shakeel Butt wrote:
> > On Wed, Sep 16, 2026 at 08:57:34PM +0800, Tao Cui wrote:
> > > From: Tao Cui <cuitao@kylinos.cn>
> > > 
> > > The legacy cgroup v1 memory controller has already been moved out of
> > > the shared implementation at the file level (mm/memcontrol-v1.c) and at
> > > the Kconfig level (CONFIG_MEMCG_V1, default n since 6.11).  Its
> > > per-cgroup state, however, still sits as individual members inside
> > > struct mem_cgroup, guarded by #ifdefs.
> > > 
> > > This series isolates the deprecated implementation from the shared hot
> > > structure: all v1-only members are grouped into a dedicated
> > > struct mem_cgroup_v1, and every access goes through memcg->v1.X.
> > > 
> > > With this in place the v1 implementation is self-contained: its
> > > interface in mm/memcontrol-v1.c, its state in struct mem_cgroup_v1, and
> > > its eventual removal becomes a localized deletion of this struct
> > > together with mm/memcontrol-v1.c, instead of unwinding
> > > ifdef-scattered members across the shared header.
> > 
> > Sorry I don't see any benefit of this code churn. The code is already behind
> > config. What exactly this code churn is giving us?
> 
> The only arguable upside is that this would make it ever so slightly
> easier to track v1 specific stuff (once that s@v1@memcg1@ or similar).

I had the same thought. It's kiiind of nice to see which members are
completely specific to memcg1.

> I am not convinced this is sufficient to justify the churn either.

IMO it helps that it's mostly in memcontrol-v1.c where the chances of
interfering with other work are pretty slim.

The patch 1 + patch 2 split is a bit bothersome: indenting everything
into a union, only to then move it out in the next patch.

Tao, if you folded these two patches to make it one clean extraction
and changed over the sites at the same time, I would probably lean
supportive on this.

Hi Shakeel, Michal,

在 2026/9/18 17:41, Michal Hocko 写道:
> On Thu 17-09-26 13:26:40, Shakeel Butt wrote:
>> On Wed, Sep 16, 2026 at 08:57:34PM +0800, Tao Cui wrote:
>>> From: Tao Cui <cuitao@kylinos.cn>
>>>
>>> The legacy cgroup v1 memory controller has already been moved out of
>>> the shared implementation at the file level (mm/memcontrol-v1.c) and at
>>> the Kconfig level (CONFIG_MEMCG_V1, default n since 6.11).  Its
>>> per-cgroup state, however, still sits as individual members inside
>>> struct mem_cgroup, guarded by #ifdefs.
>>>
>>> This series isolates the deprecated implementation from the shared hot
>>> structure: all v1-only members are grouped into a dedicated
>>> struct mem_cgroup_v1, and every access goes through memcg->v1.X.
>>>
>>> With this in place the v1 implementation is self-contained: its
>>> interface in mm/memcontrol-v1.c, its state in struct mem_cgroup_v1, and
>>> its eventual removal becomes a localized deletion of this struct
>>> together with mm/memcontrol-v1.c, instead of unwinding
>>> ifdef-scattered members across the shared header.
>>
>> Sorry I don't see any benefit of this code churn. The code is already behind
>> config. What exactly this code churn is giving us?
> 
> The only arguable upside is that this would make it ever so slightly
> easier to track v1 specific stuff (once that s@v1@memcg1@ or similar).
> I am not convinced this is sufficient to justify the churn either.

Thanks for taking a look.

You are right that the file and Kconfig layers already isolate the v1
implementation at build time, and =n builds get nothing from this
series. The benefit is only for =y builds.

In a =y build today, the deprecated controller's state is still
embedded directly in struct mem_cgroup and common code accesses it
directly. This series moves that state behind a single
struct mem_cgroup_v1, complementing the existing file- and
Kconfig-level separation at the data structure level. The layout is
unchanged, so there is no runtime cost.

My intention was to explore whether this could serve as a general
pattern for isolating the remaining cgroup v1-only state, rather than
as a standalone memcg cleanup. I should have made that context clearer
in the cover letter.

If that isn't sufficient to justify the churn, I understand.

Thanks,
Tao