From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AD1C2C433DB for ; Tue, 30 Mar 2021 21:30:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2D67D619C7 for ; Tue, 30 Mar 2021 21:30:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2D67D619C7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BC0546B007D; Tue, 30 Mar 2021 17:30:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B4A316B007E; Tue, 30 Mar 2021 17:30:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 976F06B0082; Tue, 30 Mar 2021 17:30:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id 771116B007D for ; Tue, 30 Mar 2021 17:30:13 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 22F686D95 for ; Tue, 30 Mar 2021 21:30:13 +0000 (UTC) X-FDA: 77977833906.12.22C8F29 Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) by imf01.hostedemail.com (Postfix) with ESMTP id 2CBB55001526 for ; Tue, 30 Mar 2021 21:30:12 +0000 (UTC) Received: by mail-qk1-f171.google.com with SMTP id x14so17360268qki.10 for ; Tue, 30 Mar 2021 14:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=f6+kdF3w84398U9boaR1oDCvtDMpQlwaLI1pe9v7LEU=; b=l4wWAasd+fQ1CoQ244XlM39j95UJauD9/rzsA5OhzjMVjWodjd67VeWaVybPdWBQDM 0x5rAfgDO7mA8Nih5wKFuYmQlebRfxqLpZTIHhITT47hwPEET6NhO+KX/ut4K/Y5Zc9p 31v7HTic6qWUXBZ8fxel02TpEX4brjp4d4sdR/zpHxf1RHsiIZFRS5HcMVXi8u2JtK/r xcW6vjanW2eV035wTQ8ZlZuMqn3KhWsOTtrWWvnD6+k2u32a9Uk5dGCirzA3xadZy1x9 VS7eI2iudpLhZEh7M5n+fIrvuH/FYYfCYXGpZr6iD55KSD1ONmGI6TPTXAsT9464JOzx G3mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=f6+kdF3w84398U9boaR1oDCvtDMpQlwaLI1pe9v7LEU=; b=qvuNWT7qIzgCj/IqT7bIK/9srsZZ1TuQw0qvRl9i47jRzeawy1R47lwT6c/mxp8Y1s PHzXv/t7vq1g7gn8ISbv4ZXEzTq3vFTTzaYEOiAz8713laFYnJxErFdNN5Ei5l6NpZLY a72YfzCH5jPpbmEDc3Gjb+5VdIzPRMaDSvawxWjdBsAAe7sFx4f70Q+1ATenNZWVbpvC +w4NBT8RCKutG5fLdovHIlTF9I8R9QbFZPaJATllP0YNyCBqA3+MMacdbGUb7zvxa7Ge QA487F9rbu8VP0U7s+2b1DdQikz+VbjP7kWmfWfbqGwoagHsts6vYfYPCqd5qV6UTEag /ciQ== X-Gm-Message-State: AOAM530OUKVLzmuRXRysZYrJ7Y6llzB9WdjUWEumiw1BVJFA0wMi1vNf lEXczxs2naWt9HM9iFbAQSGkDA== X-Google-Smtp-Source: ABdhPJwaIYqbEC+s/0vdTMgrMXWBSmGbRDU+ifItr1s/7q4wx1LdTHYZEmRHKIqq+QKb5MEnKXlUSw== X-Received: by 2002:a05:620a:b02:: with SMTP id t2mr310169qkg.128.1617139811787; Tue, 30 Mar 2021 14:30:11 -0700 (PDT) Received: from localhost (70.44.39.90.res-cmts.bus.ptd.net. [70.44.39.90]) by smtp.gmail.com with ESMTPSA id 131sm17707274qkl.74.2021.03.30.14.30.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Mar 2021 14:30:11 -0700 (PDT) Date: Tue, 30 Mar 2021 17:30:10 -0400 From: Johannes Weiner To: Roman Gushchin Cc: Shakeel Butt , Muchun Song , Greg Thelen , Michal Hocko , Andrew Morton , Vladimir Davydov , LKML , Linux MM , Xiongchun duan Subject: Re: [RFC PATCH 00/15] Use obj_cgroup APIs to charge the LRU pages Message-ID: References: <20210330101531.82752-1-songmuchun@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 2CBB55001526 X-Stat-Signature: c1we7z8sr7g5u3d5km4bbqdyun8dxi1x Received-SPF: none (cmpxchg.org>: No applicable sender policy available) receiver=imf01; identity=mailfrom; envelope-from=""; helo=mail-qk1-f171.google.com; client-ip=209.85.222.171 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1617139812-790374 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Mar 30, 2021 at 11:58:31AM -0700, Roman Gushchin wrote: > On Tue, Mar 30, 2021 at 11:34:11AM -0700, Shakeel Butt wrote: > > On Tue, Mar 30, 2021 at 3:20 AM Muchun Song wrote: > > > > > > Since the following patchsets applied. All the kernel memory are charged > > > with the new APIs of obj_cgroup. > > > > > > [v17,00/19] The new cgroup slab memory controller > > > [v5,0/7] Use obj_cgroup APIs to charge kmem pages > > > > > > But user memory allocations (LRU pages) pinning memcgs for a long time - > > > it exists at a larger scale and is causing recurring problems in the real > > > world: page cache doesn't get reclaimed for a long time, or is used by the > > > second, third, fourth, ... instance of the same job that was restarted into > > > a new cgroup every time. Unreclaimable dying cgroups pile up, waste memory, > > > and make page reclaim very inefficient. > > > > > > We can convert LRU pages and most other raw memcg pins to the objcg direction > > > to fix this problem, and then the LRU pages will not pin the memcgs. > > > > > > This patchset aims to make the LRU pages to drop the reference to memory > > > cgroup by using the APIs of obj_cgroup. Finally, we can see that the number > > > of the dying cgroups will not increase if we run the following test script. > > > > > > ```bash > > > #!/bin/bash > > > > > > cat /proc/cgroups | grep memory > > > > > > cd /sys/fs/cgroup/memory > > > > > > for i in range{1..500} > > > do > > > mkdir test > > > echo $$ > test/cgroup.procs > > > sleep 60 & > > > echo $$ > cgroup.procs > > > echo `cat test/cgroup.procs` > cgroup.procs > > > rmdir test > > > done > > > > > > cat /proc/cgroups | grep memory > > > ``` > > > > > > Patch 1 aims to fix page charging in page replacement. > > > Patch 2-5 are code cleanup and simplification. > > > Patch 6-15 convert LRU pages pin to the objcg direction. > > > > The main concern I have with *just* reparenting LRU pages is that for > > the long running systems, the root memcg will become a dumping ground. > > In addition a job running multiple times on a machine will see > > inconsistent memory usage if it re-accesses the file pages which were > > reparented to the root memcg. > > I agree, but also the reparenting is not the perfect thing in a combination > with any memory protections (e.g. memory.low). > > Imagine the following configuration: > workload.slice > - workload_gen_1.service memory.min = 30G > - workload_gen_2.service memory.min = 30G > - workload_gen_3.service memory.min = 30G > ... > > Parent cgroup and several generations of the child cgroup, protected by a memory.low. > Once the memory is getting reparented, it's not protected anymore. That doesn't sound right. A deleted cgroup today exerts no control over its abandoned pages. css_reset() will blow out any control settings. If you're talking about protection previously inherited by workload.slice, that continues to apply as it always has. None of this is really accidental. Per definition the workload.slice control domain includes workload_gen_1.service. And per definition, the workload_gen_1.service domain ceases to exist when you delete it. There are no (or shouldn't be any!) semantic changes from the physical unlinking from a dead control domain. > Also, I'm somewhat concerned about the interaction of the reparenting > with the writeback and dirty throttling. How does it work together? What interaction specifically? When you delete a cgroup that had both the block and the memory controller enabled, the control domain of both goes away and it becomes subject to whatever control domain is above it (if any). A higher control domain in turn takes a recursive view of the subtree, see mem_cgroup_wb_stats(), so when control is exerted, it applies regardless of how and where pages are physically linked in children. It's also already possible to enable e.g. block control only at a very high level and memory control down to a lower level. Per design this code can live with different domain sizes for memory and block.