Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp6228221pxb; Tue, 16 Feb 2021 21:38:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJzPPqqwP4J60fop0k56zmy4HfWIANBrfipIfFPGpqZM/KEo1YhihmfSoYBrHyJx3Q6aMSQD X-Received: by 2002:a17:906:5d15:: with SMTP id g21mr24885137ejt.373.1613540323629; Tue, 16 Feb 2021 21:38:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613540323; cv=none; d=google.com; s=arc-20160816; b=i/JmYWAdcB6EG4VHE6xcVLy4pSnLdmvg3Xx17Jnftwl/95dwySyzYpPDusGunwdaGJ wVubM5t+af7tlU1IH27USMgp2g5U4MYkaIiqQGRpkmYpvyU1vgG8ANk6IXxzz1l2PCsf g81580quZwtFKaziIRxOomfu7o49MxVKRnCf9Pvov4mBmjYER/EXwz7MpJhPltAuGAif kr2Pk/secCbjcMVq64QgFaBKD88rtX5bA7BEo1QqI46Sj8Sl2eJY7kN5TY57IMJ3wb91 vLJDC71WDacjnAZFg+vJvtNyVGF/Ul31qMXw0E33j2sW98fwDxjes7i18a26XuOZPpno WZgw== 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=UYvHNjsRzSj3lg/h8/eBWdl0bg6pjg+N/53V5e6DzuQ=; b=oVLOzv+QbrhW21ethBtgfF4D8PpuLP5qhVQbe3ayhpPlPSXUvx89lUPB8kKdt9Uq7c FjB42aPY4ya6wpq3NL+w3djmI6DYzHiO9ZEzkVDwdQUhTUQLU4buKX7BVSXW112cjSVs qUV+VzMgMkdvw4EXG6ntWV55JRFfyAXzvXUu83bgmdgZ3h3pCpctgPPPmjda46j8ekqe McJ+hqv+AJuM7oWgpQpGwDhWXUUIrZJhmAGb9Ru/79L7bstVbNdPzm0nae+p1fVkJr8w AK++yqs+pLpjjMxnlIocd6c1Zw/iqnlDmis3AZ6wXJpAsc23qMSioz6Yvfi+pWrv3Q1Z MzQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20150623.gappssmtp.com header.s=20150623 header.b=FCYy9NQ4; 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 w18si576463edc.255.2021.02.16.21.38.20; Tue, 16 Feb 2021 21:38:43 -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=FCYy9NQ4; 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 S230211AbhBQFNH (ORCPT + 99 others); Wed, 17 Feb 2021 00:13:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230099AbhBQFNF (ORCPT ); Wed, 17 Feb 2021 00:13:05 -0500 Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8CF44C06174A for ; Tue, 16 Feb 2021 21:12:24 -0800 (PST) Received: by mail-pg1-x536.google.com with SMTP id t11so7752087pgu.8 for ; Tue, 16 Feb 2021 21:12:24 -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=UYvHNjsRzSj3lg/h8/eBWdl0bg6pjg+N/53V5e6DzuQ=; b=FCYy9NQ49xDdGoLj67f6UIW8p2z+z+n05jGQwri581J7GMphWlV6A+j7JVZ1V5JXlS zw9Y8dvkI79zWY5zAZ0qcyiRUdO3/Nk1dMNx9diSUnZUiTTxVCxt9HhvTDzvWdshddv3 o4i+YEEs2bDjJBrpfNE5THv62gXQlLMgUplLAExWD1gktcLQT/YF1mIBh620ARqAk7rW yQVYFo6/hhqV+RyFY/2nG2ZxH2GQXGpOo4Qqd/YBcFKYgcz8hJGwZ2sw+y1ja/7a8z0U kV12YfOCH2wh+EajlGcPZaLE4+f4PCGomXnOyHnyiWRoh8VxPCAUWdrRYPqka8ZYprDM 0qZg== 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=UYvHNjsRzSj3lg/h8/eBWdl0bg6pjg+N/53V5e6DzuQ=; b=fSjBeKsi8PXfu/1NsMcaEXpwKK3srjmN6wZFhQmjaC/aMNZimyIHZJkDiLrr8/BcZv tPhrId/n6SzyzIWNFfLwkFpntlCsXwNtdTfxEWa4uE1lqkQ/w04Uo4IMXJ8YZYghaPnJ vBJl0wfAacqMQ+Y1BSnjOVJIFbtuXYcISKRZidhrWOSl1tcSwF3PzhMoYf3mk5VGm32L PmTyGBRSSLKHulCHiKmkkK4AECP3Of04yOcaOcbqPoNLSaX86lCo7hXnRP5LZ/14K5Ui IavU2Nf8auO9IYqx6z7X4L/GvmPLDqvJk74dN0a3C11uD/NQMPJIdr/GuDMpUgYcX7Vv +fzg== X-Gm-Message-State: AOAM533W8KiA5ONhYXNtf8dkDINnZOQrZDjl56yok+05ABTBEeGGyaOf uhuiuk5NqplP8mwCyDi3ift0afpwD9O0fxPYe3YdsA== X-Received: by 2002:a63:480f:: with SMTP id v15mr22395088pga.341.1613538743917; Tue, 16 Feb 2021 21:12:23 -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:11:47 +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 12:59 AM 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 > > 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: > > 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. > > Add the do_memsw_account() check back to fix this problem. Thanks. Sorry for my poor English. I should improve my changelog. > --- > > > Fixes: 2d1c498072de ("mm: memcontrol: make swap tracking an integral part of memory control") > > Signed-off-by: Muchun Song > > Acked-by: Johannes Weiner 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? I will add a comment here. Thanks. > > /* > * 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. > * > * 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. > */