Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp6228600pxb; Tue, 16 Feb 2021 21:39:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJxJ909A9b8cXYC0S94z0X5EDLBdhVbBt0YTtzcJw+eH5HDaGa+7wPCrfLbyshkL2eR4Bp4+ X-Received: by 2002:a17:906:1118:: with SMTP id h24mr24135841eja.145.1613540378815; Tue, 16 Feb 2021 21:39:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613540378; cv=none; d=google.com; s=arc-20160816; b=TYrJClN5z4UHI+Xw6suPG63WJMY9c9oTRVenwNRgKDV/53twxKVyXh/+o3pxtUmJmK PTweYl7gtOfnCNIArCTUt/njtqI7hTpLdDZTp7hMmLDApeyCmDduG53NgNyDy++Jq/kg BFXxyhP2rZNhakrHGv21eTBW7XyNqJc6Mwascy1Su8Z4VSTcom7M1Eho1AFiwpzgZmi6 OM3vvS3oWCPxbcIEwHtys8x+fmuZUlY0g9VKXGy/sboswKR39wNARqWNXvP7Ud7V6RLu Yfj37vN3pLbICv0PavS0Q+F/3tFdPRGyVhCJvbenUKrTJ/QcqGgBDCEQb5Q8nhoeW71c UU6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=nxax/8EwLpfEywaFZNrZLBQYVWz7Z8fTZrkl9WlTJsk=; b=N+E7IIiVNeISoqwmtya9TrGLATrkg2Yhqh5cvOIGH9obQp+RoTclq3lS2hKZ20edLS ywZXfB2EaDXkyU0gBmHjnoAohHp19T8MDP8Q04GX8HD+4Abrm5G+GdyuvNtioRL93b5s fvbBGw5HKy1NMABVfRPIqOpk96hrMkjtEAh6wVWLaSyqxAs8Pi/vlQd3TpNqGYMI7OCC oTR9ohZTDjOIK/3PEbA2p+IqNCuvHv8yvkdBqY/kK78ro1Ph+QvuaykzQfGG8kzd1H7s oQNoeLFvJmmkKd3OxJ6FG1Bd8S23Xudpn+Kk+Wb2/LCm5oAoX002w11sl8Rh8lmbZTm+ O/Og== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20150623.gappssmtp.com header.s=20150623 header.b=TjLBGWBA; 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=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b20si788202eje.504.2021.02.16.21.39.07; Tue, 16 Feb 2021 21:39:38 -0800 (PST) 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=@bytedance-com.20150623.gappssmtp.com header.s=20150623 header.b=TjLBGWBA; 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=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230472AbhBQFQl (ORCPT + 99 others); Wed, 17 Feb 2021 00:16:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43518 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230401AbhBQFQk (ORCPT ); Wed, 17 Feb 2021 00:16:40 -0500 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47408C061574 for ; Tue, 16 Feb 2021 21:15:54 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id f8so5221677plg.5 for ; Tue, 16 Feb 2021 21:15:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nxax/8EwLpfEywaFZNrZLBQYVWz7Z8fTZrkl9WlTJsk=; b=TjLBGWBAPyoCC0TEIegIyE/Nj8wMMOyxVs9bt3bYOem3jMqToT9VdJwPO6mqXZ2UNj rnXSlmZcsy4QebmWanmcK1+RaKkGppYn2htgoCc5LEdddP2/v+TLRB4+Wqh55c4PxWSn 67mxMG4F/PETxmfOziZ+wnIk+jMZHeuEKeZfNDIusf4qVMIZGijFNX8YoajTaHNiOJlV 3ZtZBS9AFEdFM3stjzQZuJVxZjFvG0rm1FeohggbZGcFeGJt5Hgfcvg4fPug1iFHbeBL ijcJbzONnmG3KpGK5uxM2PyaZDJlQ9/V7idkNOGcXpCu+zH69LoQgv8lIMxBIfRWxT3k 0RQA== 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=nxax/8EwLpfEywaFZNrZLBQYVWz7Z8fTZrkl9WlTJsk=; b=jRMrUOUgDbZ/X4zv3ig+CghR3i8x9glnTTatvAwyUtkITkRaKFPLgaljtUbxTcJZfj QrA68mWnEdlwNTTv2XT6msvtCNGKCmHe5/WIOE5H2Osl9nAI1cYT75EKTmKpTX8NFu34 1TsfEABoyqlzuzknPwuqA7KtirwA3jJfY/JNPQQeirfpCS8r7Ea1uSSdlCxWKqOtgmIn XFwndGmgxK84iKupp4QVoQY1Fd0UA8P4fKKxGbTJ3CHd/CR/rJriSibr2Shlp+2yy/k0 ZegnYQ5JhRAvH8g8DwsTGi84380Yex/SByV5/y9/JCnTAwRb8z6yzvRfGN62UG/lIfq7 +/3A== X-Gm-Message-State: AOAM531xxDHxULoHEd0Ji2/8Gm3KFki/l+A2m1aGfA7vAMBDFYciDJM8 zJAoe1ZT+ltSuq/v+CdA8SBrUhkE1BueImf/rN89Zw== X-Received: by 2002:a17:902:ee14:b029:e3:339d:7b3f with SMTP id z20-20020a170902ee14b02900e3339d7b3fmr18503254plb.24.1613538953666; Tue, 16 Feb 2021 21:15:53 -0800 (PST) MIME-Version: 1.0 References: <20210212170159.32153-1-songmuchun@bytedance.com> <20210212170159.32153-4-songmuchun@bytedance.com> In-Reply-To: From: Muchun Song Date: Wed, 17 Feb 2021 13:15:17 +0800 Message-ID: Subject: Re: [External] Re: [PATCH 4/4] mm: memcontrol: fix swap uncharge on cgroup v2 To: Johannes Weiner Cc: Michal Hocko , Vladimir Davydov , Andrew Morton , Cgroups , Linux Memory Management List , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 17, 2021 at 1:28 AM Johannes Weiner wrote: > > On Tue, Feb 16, 2021 at 11:59:01AM -0500, Johannes Weiner wrote: > > Hello Muchun, > > > > On Sat, Feb 13, 2021 at 01:01:59AM +0800, Muchun Song wrote: > > > The swap charges the actual number of swap entries on cgroup v2. > > > If a swap cache page is charged successful, and then we uncharge > > > the swap counter. It is wrong on cgroup v2. Because the swap > > > entry is not freed. > > > > The patch makes sense to me. But this code is a bit tricky, we should > > add more documentation to how it works and what the problem is. > > > > How about this for the changelog? > > > > --- > > mm: memcontrol: fix swap undercounting for shared pages in cgroup2 > > Coming to think of it, this isn't just for shared pages. We also hold > on to the swap slot as long as the page is read-only, not mlocked, and > swap isn't full. So scratch "for shared pages" here. OK. Will do. > > > When shared pages are swapped in partially, we can have some page > > tables referencing the in-memory page and some referencing the swap > > slot. Cgroup1 and cgroup2 handle these overlapping lifetimes slightly > > differently due to the nature of how they account memory and swap: > > Correction: > > When pages are swapped in, the VM may retain the swap copy to avoid > repeated writes in the future. It's also retained if shared pages are > faulted back in some processes, but not in others. During that time we > have an in-memory copy of the page, as well as an on-swap > copy. Cgroup1 and cgroup2 handle these overlapping lifetimes slightly > differently due to the nature of how they account memory and swap: Thanks a lot. > > > Cgroup1 has a unified memory+swap counter that tracks a data page > > regardless whether it's in-core or swapped out. On swapin, we transfer > > the charge from the swap entry to the newly allocated swapcache page, > > even though the swap entry might stick around for a while. That's why > > we have a mem_cgroup_uncharge_swap() call inside mem_cgroup_charge(). > > > > Cgroup2 tracks memory and swap as separate, independent resources and > > thus has split memory and swap counters. On swapin, we charge the > > newly allocated swapcache page as memory, while the swap slot in turn > > must remain charged to the swap counter as long as its allocated too. > > > > The cgroup2 logic was broken by commit 2d1c498072de ("mm: memcontrol: > > make swap tracking an integral part of memory control"), because it > > accidentally removed the do_memsw_account() check in the branch inside > > mem_cgroup_uncharge() that was supposed to tell the difference between > > the charge transfer in cgroup1 and the separate counters in cgroup2. > > > > As a result, cgroup2 currently undercounts consumed swap when shared > > pages are partially swapped back in. This in turn allows a cgroup to > > consume more swap than its configured limit intends. > > Correction: > > As a result, cgroup2 currently undercounts retained swap to varying > degrees: swap slots are cached up to 50% of the configured limit or > total available swap space; partially faulted back shared pages are > only limited by physical capacity. This in turn allows cgroups to > significantly overconsume their alloted swap space. Thanks a lot. > > > Add the do_memsw_account() check back to fix this problem. > > --- > > > > > Fixes: 2d1c498072de ("mm: memcontrol: make swap tracking an integral part of memory control") > > > Signed-off-by: Muchun Song > > > > Acked-by: Johannes Weiner > > I also think we should tag stable on this one. The potential > accounting error is quite large and, even without concrete examples, > is likely to cause problems for swap management in the real world. > > Cc: stable@vger.kernel.org # 5.8+ OK. I will add a Cc stable tag. Thanks. > > > > mm/memcontrol.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > > index c737c8f05992..be6bc5044150 100644 > > > --- a/mm/memcontrol.c > > > +++ b/mm/memcontrol.c > > > @@ -6753,7 +6753,7 @@ int mem_cgroup_charge(struct page *page, struct mm_struct *mm, gfp_t gfp_mask) > > > memcg_check_events(memcg, page); > > > local_irq_enable(); > > > > > > - if (PageSwapCache(page)) { > > > + if (!cgroup_subsys_on_dfl(memory_cgrp_subsys) && PageSwapCache(page)) { > > > > It's more descriptive to use do_memsw_account() here, IMO. > > > > We should also add a comment. How about this above the branch? > > > > /* > > * Cgroup1's unified memory+swap counter has been charged with the > > * new swapcache page, finish the transfer by uncharging the swap > > * slot. The swap slot would also get uncharged when it dies, but > > * for shared pages it can stick around indefinitely and we'd count > > * the page twice the entire time. > > -for shared pages > > > * Cgroup2 has separate resource counters for memory and swap, > > * so this is a non-issue here. Memory and swap charge lifetimes > > * correspond 1:1 to page and swap slot lifetimes: we charge the > > * page to memory here, and uncharge swap when the slot is freed. > > */