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 8746FC433DB for ; Fri, 12 Mar 2021 23:07:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EE36164F89 for ; Fri, 12 Mar 2021 23:07:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EE36164F89 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 4B9AB6B006C; Fri, 12 Mar 2021 18:07:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 46A246B006E; Fri, 12 Mar 2021 18:07:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 30AA06B0070; Fri, 12 Mar 2021 18:07:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0245.hostedemail.com [216.40.44.245]) by kanga.kvack.org (Postfix) with ESMTP id 119716B006C for ; Fri, 12 Mar 2021 18:07:43 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id B7409183C8CC2 for ; Fri, 12 Mar 2021 23:07:42 +0000 (UTC) X-FDA: 77912761164.29.C4B88AA Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) by imf18.hostedemail.com (Postfix) with ESMTP id 07B3F257A36C for ; Fri, 12 Mar 2021 23:07:21 +0000 (UTC) Received: by mail-qk1-f180.google.com with SMTP id d20so26129597qkc.2 for ; Fri, 12 Mar 2021 15:07:20 -0800 (PST) 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=HAWUFqDRsl0lKLydzEvVMYU91e/yIqLXEOvNq/hwJqM=; b=oA1bo+kDeW9dkhGQjpbyrvQr7fQBvTy0fC3+V1fjLUG5W4gAFJWqhEUcovl32HC2BK xtbIIu8rLER2gAShaOCaz1ln4C6bEk4XPi+GidYNGfLbJAB0rrOYmpwNsdIn+wskv90h OpjoK/mTjDKahBIqaqOV3P45KWvkGfRPPoZjEZUfL4GCrOpSxJKlKqw3n4FAo3oyrZv4 q3g7TbYP/CD3EDgst23vFD3RYiJxLWIkNtHDiJ2aqr4LYlmYRIwopVn7JqK4IycctlZf qpJQFOu/jM1HvDEuZRql6oj5o3i/iiv8wfp1u4EoZmAQfvJznERa4Ds/YbaL9nfgrZVt hHoA== 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=HAWUFqDRsl0lKLydzEvVMYU91e/yIqLXEOvNq/hwJqM=; b=PTT9JWOQTrWYC3WsfUqMudpYUokRXKktbCF1I4EEAMsKwCwcXW9xk7+4doyM2jQC9K BB3oFPTSO5rIBLIJTk99o4a4IMb2s8u099xV+sCCmjEfLEfjaQsMgLibAdTtXWEHy2Zp L4CV3V/dBd3+vG8wOW6fhPUzoH4Y0tDF3L5G291IiLasLIsF/DYZbO8H2lhekcgWNkxa 5zY9nKw+9MB1ILV55xoMSXf3yYgODOHTCCEqrY4y44L4MiXh00wGdcv4ftDJo245M/Xw tE2DUMMAOJgYeIBZ7Oi86VUKHmwmJME9fmYgqYazINDbvER7XegATOB5ZgK+TKXwFot8 Sr3Q== X-Gm-Message-State: AOAM531XEDgrUIwmilUsnxptSwIlvAorpn01MkyG5m0FDhtuSiz1rzYl 2d/ZJym5lvWiMaEwq92XrD2yYA== X-Google-Smtp-Source: ABdhPJxKwzD6dI/j0cDEYqXK+pwMw9Bs9xP09zaVtJeLlXPDAWvbxod2xcXdmblXkgfX7YcPVOTlfQ== X-Received: by 2002:a37:4643:: with SMTP id t64mr14631379qka.344.1615590440098; Fri, 12 Mar 2021 15:07:20 -0800 (PST) Received: from localhost ([2620:10d:c091:480::1:e6d2]) by smtp.gmail.com with ESMTPSA id q187sm5477897qkb.36.2021.03.12.15.07.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Mar 2021 15:07:19 -0800 (PST) Date: Fri, 12 Mar 2021 18:07:18 -0500 From: Johannes Weiner To: Shakeel Butt Cc: Muchun Song , Roman Gushchin , Michal Hocko , Andrew Morton , Vladimir Davydov , LKML , Linux Memory Management List , Xiongchun duan Subject: Re: [External] Re: [PATCH v3 2/4] mm: memcontrol: make page_memcg{_rcu} only applicable for non-kmem page Message-ID: References: <20210309100717.253-1-songmuchun@bytedance.com> <20210309100717.253-3-songmuchun@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: uiyk9hizjr5838uadrtttjhfpn1d6q8t X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 07B3F257A36C Received-SPF: none (cmpxchg.org>: No applicable sender policy available) receiver=imf18; identity=mailfrom; envelope-from=""; helo=mail-qk1-f180.google.com; client-ip=209.85.222.180 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615590441-330518 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 Fri, Mar 12, 2021 at 02:42:45PM -0800, Shakeel Butt wrote: > Hi Johannes, > > On Fri, Mar 12, 2021 at 11:23 AM Johannes Weiner wrote: > > > [...] > > > > Longer term we most likely need it there anyway. The issue you are > > describing in the cover letter - allocations 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. > > > > For the scenario described above, do we really want to reparent the > page cache pages? Shouldn't we recharge the pages to the second, > third, fourth and so on, memcgs? My concern is that we will see a big > chunk of page cache pages charged to root and will only get reclaimed > on global pressure. Sorry, I'm proposing to reparent to the ancestor, not root. It's an optimization, not a change in user-visible behavior. As far as the user can tell, the pages already belong to the parent after deletion: they'll show up in the parent's stats, naturally, and they will get reclaimed as part of the parent being reclaimed. The dead cgroup doesn't even have its own limit anymore after .css_reset() has run. And we already physically reparent slab objects in memcg_reparent_objcgs() and memcg_drain_all_list_lrus(). I'm just saying we should do the same thing for LRU pages.