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=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL autolearn=ham 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 36F98C433DB for ; Tue, 16 Feb 2021 17:17:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 079E364E08 for ; Tue, 16 Feb 2021 17:17:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230517AbhBPRR0 (ORCPT ); Tue, 16 Feb 2021 12:17:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59384 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230429AbhBPRRX (ORCPT ); Tue, 16 Feb 2021 12:17:23 -0500 Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BEC11C061574 for ; Tue, 16 Feb 2021 09:16:37 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id j6so12806757ljo.5 for ; Tue, 16 Feb 2021 09:16:37 -0800 (PST) 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=E45USrfwyuPTU85r3q5N9FFFgs4PphB6lqH5aUk4Cag=; b=uKAmePCYTggNcKv8e6HwrE/wfBPlHBLs09fukIDn1Ad8eGiyXdq6UVoUHACc5UoJCE 3zvOhCdBL7paJpiTVqgjW/9Ln+PbRjS+i/9EK2u5XKpZQ8iRUEu1fvlDnBpoENJ61vJV xamLT1E0WOt/77sNcTXjJxBpkwIl5RrePfmtw0KFg2DKLqob1a4wdYxNfEB6iY+zZQLh T73T2gxzFEIfdIthKZ+fVjxhiCYxIDTziJVgXH7GQiAJOCvGXQZK0xyN017joVbw4A0I vLlIr+HnHG9caI+/8IiRynC1jQ7pDqyTTR8CIPFBsuFA8z4k9Hp5BTpdMneZU8Fsi1uF 2WVg== 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=E45USrfwyuPTU85r3q5N9FFFgs4PphB6lqH5aUk4Cag=; b=Ev3MRDUvFgM2o+VyfNRneuwGlkt9KKY/9+fy/+LKRNqEG4DG3QVGKmc0NrxCSh5K70 HBaHttCuu5eICkjsi8GEiIx9vbLX4H0/1XOtUbxfe5Ki0K5B3bPqhOeSTuDvVirEnNoh WqxwbtT5GAx0EGsGffSMO9y3Reo0YSGkrsoeNug0ip6TPiWLMnAhLfZFSVctyvYeym/4 53FFNEFfQEjerepO5s8sns59BpmvGVueV0qPWpuLrkZwlOgEFyJuYE4CYwJq52ZXE7Nt yrYmuu6W1UvIVvDhhQXz9EaBmhjx6L7ESy5U2lMEKX1LIaEcIcvS0KRHXdgS6oe+sYO6 myPQ== X-Gm-Message-State: AOAM533pUGX702IQjCBC5G8ZHt4uIUyNLcbeX7hjcBVKrnmIydAkBqfP 9FUuyr96VEt4PlRP4MeMwEUINWsJ8a/jsaKXD4xmPQ== X-Google-Smtp-Source: ABdhPJwjYb7W4T0wg5Hy1MX2CVcAVbqrij6GPD2ReASzI+sXBNljFD1GbZ8juc2sgDG5QDu7KhRrecY1CRdwaSiFg6E= X-Received: by 2002:a2e:9806:: with SMTP id a6mr12304184ljj.456.1613495795934; Tue, 16 Feb 2021 09:16:35 -0800 (PST) MIME-Version: 1.0 References: <20210212170159.32153-1-songmuchun@bytedance.com> <20210212170159.32153-4-songmuchun@bytedance.com> In-Reply-To: From: Shakeel Butt Date: Tue, 16 Feb 2021 09:16:24 -0800 Message-ID: Subject: Re: [External] Re: [PATCH 4/4] mm: memcontrol: fix swap uncharge on cgroup v2 To: Muchun Song Cc: Huang Ying , Tim Chen , Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Cgroups , Linux MM , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 12, 2021 at 10:48 PM Muchun Song wrote: > > On Sat, Feb 13, 2021 at 2:57 AM Shakeel Butt wrote: > > > > CCing more folks. > > > > On Fri, Feb 12, 2021 at 9:14 AM 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. > > > > > > Fixes: 2d1c498072de ("mm: memcontrol: make swap tracking an integral part of memory control") > > > Signed-off-by: Muchun Song > > > > What's the user visible impact of this change? > > IIUC, I think that we cannot limit the swap to memory.swap.max > on cgroup v2. > > cd /sys/fs/cgroup/ > mkdir test > cd test > echo 8192 > memory.max > echo 4096 > memory.swap.max > > OK. Now we limit swap to 1 page and memory to 2 pages. > Firstly, we allocate 1 page from this memory cgroup and > swap this page to swap disk. We can see: > > memory.current: 0 > memory.swap.current: 1 > > Then we touch this page, we will swap in and charge > the swap cache page to the memory counter and uncharge > the swap counter. > > memory.current: 1 > memory.swap.current: 0 (but actually we use a swap entry) > > Then we allocate another 1 page from this memory cgroup. > > memory.current: 2 > memory.swap.current: 0 (but actually we use a swap entry) > > If we swap those 2 pages to swap disk. We can charge and swap > those 2 pages successfully. Right? Maybe I am wrong. > I was trying to repro this but couldn't and later remembered that swap on zram skips the swapcache and thus is not impacted by this issue. This is reproducible on swap on disk and I see Johannes has already described in good detail. 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=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL autolearn=ham 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 C3FF7C433DB for ; Tue, 16 Feb 2021 17:16:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5A3F264E07 for ; Tue, 16 Feb 2021 17:16:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5A3F264E07 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A21FD6B0005; Tue, 16 Feb 2021 12:16:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D2EB6B0006; Tue, 16 Feb 2021 12:16:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89BE36B006C; Tue, 16 Feb 2021 12:16:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0133.hostedemail.com [216.40.44.133]) by kanga.kvack.org (Postfix) with ESMTP id 761EB6B0005 for ; Tue, 16 Feb 2021 12:16:38 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 38F46249D for ; Tue, 16 Feb 2021 17:16:38 +0000 (UTC) X-FDA: 77824785276.30.037F291 Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf27.hostedemail.com (Postfix) with ESMTP id DF86A80192D5 for ; Tue, 16 Feb 2021 17:16:34 +0000 (UTC) Received: by mail-lj1-f173.google.com with SMTP id c8so10590204ljd.12 for ; Tue, 16 Feb 2021 09:16:37 -0800 (PST) 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=E45USrfwyuPTU85r3q5N9FFFgs4PphB6lqH5aUk4Cag=; b=uKAmePCYTggNcKv8e6HwrE/wfBPlHBLs09fukIDn1Ad8eGiyXdq6UVoUHACc5UoJCE 3zvOhCdBL7paJpiTVqgjW/9Ln+PbRjS+i/9EK2u5XKpZQ8iRUEu1fvlDnBpoENJ61vJV xamLT1E0WOt/77sNcTXjJxBpkwIl5RrePfmtw0KFg2DKLqob1a4wdYxNfEB6iY+zZQLh T73T2gxzFEIfdIthKZ+fVjxhiCYxIDTziJVgXH7GQiAJOCvGXQZK0xyN017joVbw4A0I vLlIr+HnHG9caI+/8IiRynC1jQ7pDqyTTR8CIPFBsuFA8z4k9Hp5BTpdMneZU8Fsi1uF 2WVg== 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=E45USrfwyuPTU85r3q5N9FFFgs4PphB6lqH5aUk4Cag=; b=ljV2y7sYFKAC8tQpDo8hrDOo8uzsRbZpWMnbxhBsc1lLlcHtIfLTXenp9OOBWgPdFU GAVgXTyNDqOGph+Z2ZfLz47ug+SM6ghSH+uRtO6/n3ei9MXPOZZu/TQlmrXx3NBAW53p +pwWjiW/OUcjq0mw3pKfkI9tAdXzbLgNP1QlwD0N4xx3AEnVD9PupjMFzL8Vh7ffaj0H Kml8hrqtOAdFpcdBM+CWSgvRaMjyYYYen/3TlzePcivlSqPTqTTYyz5lfiCcM3S99CGZ K+qfZW8dFVaoUBx4h7QTTm0cnFdJsrdsNaNnr23cTZvoqbSAV7+7D/dKfBkzFuzi/RaI p7PA== X-Gm-Message-State: AOAM530xBh9eLez+A/YKplmwI8IxLLj8CHMUqIboJFyqXy0l7AwuFCOi SVicBYZ+9v8g9jXEclgfdRlfdr88JIa/jZmlvcl8vA== X-Google-Smtp-Source: ABdhPJwjYb7W4T0wg5Hy1MX2CVcAVbqrij6GPD2ReASzI+sXBNljFD1GbZ8juc2sgDG5QDu7KhRrecY1CRdwaSiFg6E= X-Received: by 2002:a2e:9806:: with SMTP id a6mr12304184ljj.456.1613495795934; Tue, 16 Feb 2021 09:16:35 -0800 (PST) MIME-Version: 1.0 References: <20210212170159.32153-1-songmuchun@bytedance.com> <20210212170159.32153-4-songmuchun@bytedance.com> In-Reply-To: From: Shakeel Butt Date: Tue, 16 Feb 2021 09:16:24 -0800 Message-ID: Subject: Re: [External] Re: [PATCH 4/4] mm: memcontrol: fix swap uncharge on cgroup v2 To: Muchun Song Cc: Huang Ying , Tim Chen , Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Cgroups , Linux MM , LKML Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: hdeoksoq595yooxfgbuxpzp5chgtesa6 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: DF86A80192D5 Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf27; identity=mailfrom; envelope-from=""; helo=mail-lj1-f173.google.com; client-ip=209.85.208.173 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1613495794-484564 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, Feb 12, 2021 at 10:48 PM Muchun Song wrote: > > On Sat, Feb 13, 2021 at 2:57 AM Shakeel Butt wrote: > > > > CCing more folks. > > > > On Fri, Feb 12, 2021 at 9:14 AM 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. > > > > > > Fixes: 2d1c498072de ("mm: memcontrol: make swap tracking an integral part of memory control") > > > Signed-off-by: Muchun Song > > > > What's the user visible impact of this change? > > IIUC, I think that we cannot limit the swap to memory.swap.max > on cgroup v2. > > cd /sys/fs/cgroup/ > mkdir test > cd test > echo 8192 > memory.max > echo 4096 > memory.swap.max > > OK. Now we limit swap to 1 page and memory to 2 pages. > Firstly, we allocate 1 page from this memory cgroup and > swap this page to swap disk. We can see: > > memory.current: 0 > memory.swap.current: 1 > > Then we touch this page, we will swap in and charge > the swap cache page to the memory counter and uncharge > the swap counter. > > memory.current: 1 > memory.swap.current: 0 (but actually we use a swap entry) > > Then we allocate another 1 page from this memory cgroup. > > memory.current: 2 > memory.swap.current: 0 (but actually we use a swap entry) > > If we swap those 2 pages to swap disk. We can charge and swap > those 2 pages successfully. Right? Maybe I am wrong. > I was trying to repro this but couldn't and later remembered that swap on zram skips the swapcache and thus is not impacted by this issue. This is reproducible on swap on disk and I see Johannes has already described in good detail. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shakeel Butt Subject: Re: [External] Re: [PATCH 4/4] mm: memcontrol: fix swap uncharge on cgroup v2 Date: Tue, 16 Feb 2021 09:16:24 -0800 Message-ID: References: <20210212170159.32153-1-songmuchun@bytedance.com> <20210212170159.32153-4-songmuchun@bytedance.com> Mime-Version: 1.0 Return-path: 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=E45USrfwyuPTU85r3q5N9FFFgs4PphB6lqH5aUk4Cag=; b=uKAmePCYTggNcKv8e6HwrE/wfBPlHBLs09fukIDn1Ad8eGiyXdq6UVoUHACc5UoJCE 3zvOhCdBL7paJpiTVqgjW/9Ln+PbRjS+i/9EK2u5XKpZQ8iRUEu1fvlDnBpoENJ61vJV xamLT1E0WOt/77sNcTXjJxBpkwIl5RrePfmtw0KFg2DKLqob1a4wdYxNfEB6iY+zZQLh T73T2gxzFEIfdIthKZ+fVjxhiCYxIDTziJVgXH7GQiAJOCvGXQZK0xyN017joVbw4A0I vLlIr+HnHG9caI+/8IiRynC1jQ7pDqyTTR8CIPFBsuFA8z4k9Hp5BTpdMneZU8Fsi1uF 2WVg== In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Muchun Song Cc: Huang Ying , Tim Chen , Johannes Weiner , Michal Hocko , Vladimir Davydov , Andrew Morton , Cgroups , Linux MM , LKML On Fri, Feb 12, 2021 at 10:48 PM Muchun Song wrote: > > On Sat, Feb 13, 2021 at 2:57 AM Shakeel Butt wrote: > > > > CCing more folks. > > > > On Fri, Feb 12, 2021 at 9:14 AM 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. > > > > > > Fixes: 2d1c498072de ("mm: memcontrol: make swap tracking an integral part of memory control") > > > Signed-off-by: Muchun Song > > > > What's the user visible impact of this change? > > IIUC, I think that we cannot limit the swap to memory.swap.max > on cgroup v2. > > cd /sys/fs/cgroup/ > mkdir test > cd test > echo 8192 > memory.max > echo 4096 > memory.swap.max > > OK. Now we limit swap to 1 page and memory to 2 pages. > Firstly, we allocate 1 page from this memory cgroup and > swap this page to swap disk. We can see: > > memory.current: 0 > memory.swap.current: 1 > > Then we touch this page, we will swap in and charge > the swap cache page to the memory counter and uncharge > the swap counter. > > memory.current: 1 > memory.swap.current: 0 (but actually we use a swap entry) > > Then we allocate another 1 page from this memory cgroup. > > memory.current: 2 > memory.swap.current: 0 (but actually we use a swap entry) > > If we swap those 2 pages to swap disk. We can charge and swap > those 2 pages successfully. Right? Maybe I am wrong. > I was trying to repro this but couldn't and later remembered that swap on zram skips the swapcache and thus is not impacted by this issue. This is reproducible on swap on disk and I see Johannes has already described in good detail.