linux-kernel - Re: [PATCH] mm, memcg: expose swapcache stat for memcg v1

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] [day] [month] [year] [list]

Message-ID: <CAJD7tkYY7je3x-MRhayyrC0xCFvKZO8CuiEnQHanF5_ErZ2n6Q@mail.gmail.com>
Date:   Tue, 26 Sep 2023 01:22:47 -0700
From:   Yosry Ahmed <yosryahmed@...gle.com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Liu Shixin <liushixin2@...wei.com>, Tejun Heo <tj@...nel.org>,
        Zefan Li <lizefan.x@...edance.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Jonathan Corbet <corbet@....net>,
        Michal Hocko <mhocko@...nel.org>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Shakeel Butt <shakeelb@...gle.com>,
        Muchun Song <muchun.song@...ux.dev>,
        Kefeng Wang <wangkefeng.wang@...wei.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        cgroups@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] mm, memcg: expose swapcache stat for memcg v1

On Tue, Sep 26, 2023 at 12:30 AM Christoph Hellwig <hch@...radead.org> wrote:
>
> On Sat, Sep 02, 2023 at 06:07:28PM +0800, Liu Shixin wrote:
> > Since commit b6038942480e ("mm: memcg: add swapcache stat for memcg v2")
> > adds swapcache stat for the cgroup v2, it seems there is no reason to
> > hide it in memcg v1. Conversely, with swapcached it is more accurate to
> > evaluate the available memory for memcg.
>
> Why are we adding new features to the long deprecated cgroup v1?
>

Technically this is not a new feature, we are just exposing a stat
that the kernel is already tracking (for both cgroup v1 and v2).

The reason I suggested to expose this for cgroup v1 is because a
recent series [1] started using this stat in the kernel to make some
reclaim decisions, for both cgroup v1 and v2. Exposing the stat in v1
will make sure no one assumes the stat is only useful for v2 and break
the tracking for v1 (which might cause some reclaim regressions then).

[1]https://lore.kernel.org/lkml/20230915083417.3190512-1-liushixin2@huawei.com/