Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp780170ybh; Tue, 21 Jul 2020 07:48:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxmxoPhREAR/E5+NOZMeJuxinks1KD/PBrTt8H1yxrEOmHs1BxAHzLnw4/7UZfne3z+UsuU X-Received: by 2002:a17:906:5657:: with SMTP id v23mr26417036ejr.196.1595342898448; Tue, 21 Jul 2020 07:48:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595342898; cv=none; d=google.com; s=arc-20160816; b=yPoW5KpMhZmMbMgX7/8QIlmI0C3fksDAjlUo6X5IEdAJfI9CMxWXRGLpeN79omm0au hA+FqJtkwi74D8buCBNT2DZA1UXU1lwwdPRBBIKKf49fkh4HkgGAzLECZX50XaRwmwrj dCboLqwBMvsnuOK3q/kmsW0ufx3njmYDzhQKo8404otqJgMnLHeBz0i67EM0BZXvey5B 3x+aDVKE1fQEj9zvU+9ySiUFx/ttyV0PI6/PV4ZLTw/bKUeCt9lQ2AInrR/na/yZin1s bMHZY1xxCPg15MPzCwuG2Zl7hRovDKN/zdfudWzpnNlx4G6ZYNAsB6j1KUUt13s9Kgcp wVLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=0pAwByUR93Lcw7763OHJXsSvUvLTrNih6qhx4gjT+aM=; b=RvlvBWayEaMHKm60FXy4mP8s3gN57k8m2Rd47CSaAY7ux/y2B/gSsYthHvAohPGX6g HghB1thFr4zvt2zmOKea3qZ4feQrfjx6lNslI1mJB4NyAPKUSSRmszILnGhGX7tMNfdU Afxxuunqt+35jlS4wSF222ujhz0FqICXRlTNXbTXmYsdJemHmek98TUJ9ABQhOE7+A9R LpS1fRK+aw7JLOTm8BIzJMcb6kOKuBcsWPiWGBotMlAshKJJoH8t+8F6ycRU/TM2/cQF gUiTcLJq0d3XqsXgmwiJzCjasLNBT18lwqGWQKubpi1a6Xb2p5mkZfSKLfBtpj2vO1qm OCcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=RJPk4UVm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id rp11si12464700ejb.280.2020.07.21.07.47.55; Tue, 21 Jul 2020 07:48:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=RJPk4UVm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728931AbgGUOp2 (ORCPT + 99 others); Tue, 21 Jul 2020 10:45:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56838 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726412AbgGUOp2 (ORCPT ); Tue, 21 Jul 2020 10:45:28 -0400 Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A18F1C061794 for ; Tue, 21 Jul 2020 07:45:27 -0700 (PDT) Received: by mail-lf1-x143.google.com with SMTP id i80so11803507lfi.13 for ; Tue, 21 Jul 2020 07:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0pAwByUR93Lcw7763OHJXsSvUvLTrNih6qhx4gjT+aM=; b=RJPk4UVm3QG1OSNEE3CsSct0ln7CZy0uNFBtNkbOJqVixfV+ABWf25M4H+TnYcPfce Ta+awLrH5yk/hEx+EREuJMfro+hKQpGe5CFLuXIivkB9MRt63Mgki6+ZSqsYmq60+KGR saMyvxi2Hmz1v1xQI2GSgfDNxXTFo1iMzKVWjBJjRBqfCJ1CmI8KNgJBdaDfPJ2tuRhc 1B2BJWsw4BWQe4cDBiWCe26f3Sag/jnK6MVlPixWUeRZaxdJW6M9dd3rU+dU/oYLU+7I NhW4hltGvXPB7wF1uCgYh08R3vYJ9kwAMy5b5J9dOBkBQSe9QqK7WkCSf+m3yniK49H9 NTuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0pAwByUR93Lcw7763OHJXsSvUvLTrNih6qhx4gjT+aM=; b=OO2/HdQze7WuLxNvZxX7CulsKBQm4IV+MPkm3a+eTWGnyE2nkuwX9VHY/imZyZU4kB nd7M8xhVVZga8e5rradhWJ31yv1xOVvlLXMuNvdYQbbQ01LiTkQKPLccly8R/nmBAFWZ sHRzkX4+l6W3KTl3FW3OncLxfbfsyHlwK3SskO/m/0yNo4w3JYcBSrOuvOuRxTA9/Y/9 59Vzc6+hPRCUzEyBSS8S/iXTW1L/EA42mvyM0WAmbyAfPK5z+RC1xetvpvbkN7NGRL1D vJ0rh6/5j46EpX35wZsgZ8gKdDnDkMR5b8k/X0n7Z/NDOIo5CoKmLCRxjugdoyRfwQiV mDwg== X-Gm-Message-State: AOAM531sK/liFDJyVVzRzZgqix1NrSR6u5tbv7EUtaDwbEJ0qYpNykDW jcNUPuunJ4ouniL2gOVi7cYRaHMsHleSY08DhFjUrA== X-Received: by 2002:ac2:4183:: with SMTP id z3mr10668274lfh.3.1595342725776; Tue, 21 Jul 2020 07:45:25 -0700 (PDT) MIME-Version: 1.0 References: <2E04DD7753BE0E4ABABF0B664610AD6F2620CAF7@dggeml528-mbx.china.huawei.com> In-Reply-To: <2E04DD7753BE0E4ABABF0B664610AD6F2620CAF7@dggeml528-mbx.china.huawei.com> From: Shakeel Butt Date: Tue, 21 Jul 2020 07:45:14 -0700 Message-ID: Subject: Re: PROBLEM: cgroup cost too much memory when transfer small files to tmpfs To: jingrui Cc: "tj@kernel.org" , Lizefan , "hannes@cmpxchg.org" , "mhocko@kernel.org" , "vdavydov.dev@gmail.com" , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "cgroups@vger.kernel.org" , "linux-kernel@vger.kernel.org" , caihaomin , "Weiwei (N)" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 21, 2020 at 4:20 AM jingrui wrote: > > Cc: Johannes Weiner ; Michal Hocko ; Vladimir Davydov > > 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. Is there a way for you to re-use the cgroup instead of creating and deleting cgroup for each individual file transfer session? > The PERCPU memory in cgroup/css object > cost a lot(about 0.5MB/per-cgroup-object) on 200/cpus machine. > > When lot of small files transferred to tmpfs, the cgroup/css object memory > cost become huge in this scenes to be used. > > systemd related issue: https://github.com/systemd/systemd/issues/16499 > > kernel version: 4.19+ > > Problem: > > 1. Do we have any idea to descrease cgroup memory cost in this case? > 2. When user remove cgroup directory, does it possible associated file memory to root cgroup? No, the memory remains associated with the cgroup and the cgroup becomes zombie on deletion. > 3. Can we provide an option that do not associate memory with cgroup in tmpfs? Only way, if you don't want to disable memcg, is to move the file receiver process to root cgroup.