linux-kernel - Re: PROBLEM: cgroup cost too much memory when transfer small files to tmpfs

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20200721192749.GB8266@carbon.DHCP.thefacebook.com>
Date:   Tue, 21 Jul 2020 12:27:49 -0700
From:   Roman Gushchin <guro@...com>
To:     Shakeel Butt <shakeelb@...gle.com>
CC:     Johannes Weiner <hannes@...xchg.org>, jingrui <jingrui@...wei.com>,
        "tj@...nel.org" <tj@...nel.org>, Lizefan <lizefan@...wei.com>,
        "mhocko@...nel.org" <mhocko@...nel.org>,
        "vdavydov.dev@...il.com" <vdavydov.dev@...il.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "cgroups@...r.kernel.org" <cgroups@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        caihaomin <caihaomin@...wei.com>,
        "Weiwei (N)" <wick.wei@...wei.com>, <guro@...xchg.org>
Subject: Re: PROBLEM: cgroup cost too much memory when transfer small files
 to tmpfs

On Tue, Jul 21, 2020 at 12:12:58PM -0700, Shakeel Butt wrote:
> On Tue, Jul 21, 2020 at 11:51 AM Roman Gushchin <guro@...com> wrote:
> >
> > On Tue, Jul 21, 2020 at 01:41:26PM -0400, Johannes Weiner wrote:
> > > On Tue, Jul 21, 2020 at 11:19:52AM +0000, jingrui wrote:
> > > > Cc: Johannes Weiner <hannes@...xchg.org> ; Michal Hocko <mhocko@...nel.org>; Vladimir Davydov <vdavydov.dev@...il.com>
> > > >
> > > > Thanks.
> > > >
> > > > ---
> > > > PROBLEM: cgroup cost too much memory when transfer small files to tmpfs.
> > > >
> > > > keywords: cgroup PERCPU/memory cost too much.
> > > >
> > > > description:
> > > >
> > > > We send small files from node-A to node-B tmpfs /tmp directory using sftp. On
> > > > node-B the systemd configured with pam on like below.
> > > >
> > > > cat /etc/pam.d/password-auth | grep systemd
> > > > -session     optional      pam_systemd.so
> > > >
> > > > So when transfer a file, a systemd session is created, that means a cgroup is
> > > > created, then file saved at /tmp will associated with a cgroup object. After
> > > > file transferred, session and cgroup-dir will be removed, but the file in /tmp
> > > > still associated with the cgroup object. The PERCPU memory in cgroup/css object
> > > > cost a lot(about 0.5MB/per-cgroup-object) on 200/cpus machine.
> > >
> > > CC Roman who had a patch series to free all this extended (percpu)
> > > memory upon cgroup deletion:
> > >
> > > https://lore.kernel.org/patchwork/cover/1050508/
> > >
> > > It looks like it never got merged for some reason.
> >
> > The mentioned patchset can make the problem less noticeable, but can't solve it completely.
> > It has never been merged, because the dying cgroup problem was mostly solved by other methods:
> > slab memory reparenting and various reclaim fixes. So there was no more reason to complicate
> > the code to release the memcg memory early.
> >
> > The overhead of creating and destroying a new memory cgroup for a transfer of a small
> > file will be noticeable anyway. So IMO the solution is to use a single cgroup for all
> > transfers. I don't know if systemd supports such mode out of the box, but it shouldn't
> > be hard to add it.
> >
> > But also I wonder if we need a special tmpfs mount option, something like "noaccount".
> > Not only for this specific case, but also for the case when tmpfs is extensively
> > shared between multiple cgroups or if it's used to pass some data from one cgroup
> > to another, or if we care about the performance more than about the accounting;
> > in other words for cases where the accounting makes more harm than good.
> >
> 
> Internally we actually have an tmpfs mount option "memcg=" which
> charges all the memory of the tmpfs files on that mount to the given
> memcg and the motivation is the shared tmpfs files between multiple
> cgroups. One concrete use-case is the shared memory used for
> communication between the application and the user space network
> driver [1]. The "memcg=root" can be used as a "noaccount" option.

It sounds like a good idea to me. I'm slightly worried about possible
security implications of allowing to pass a custom cgroup, but I guess
we can start with supporting the root cgroup only.

Thanks!