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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8CEE8C433EF for ; Tue, 28 Sep 2021 07:15:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1E939611CA for ; Tue, 28 Sep 2021 07:15:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1E939611CA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 303CD900003; Tue, 28 Sep 2021 03:15:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B41F900002; Tue, 28 Sep 2021 03:15:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A2F8900003; Tue, 28 Sep 2021 03:15:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0123.hostedemail.com [216.40.44.123]) by kanga.kvack.org (Postfix) with ESMTP id 0CED2900002 for ; Tue, 28 Sep 2021 03:15:57 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id BAD9F1801AB63 for ; Tue, 28 Sep 2021 07:15:56 +0000 (UTC) X-FDA: 78636122712.25.DE77547 Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) by imf12.hostedemail.com (Postfix) with ESMTP id 6F02D10000AB for ; Tue, 28 Sep 2021 07:15:56 +0000 (UTC) Received: by mail-vs1-f48.google.com with SMTP id az15so20973290vsb.8 for ; Tue, 28 Sep 2021 00:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Fp6qne4sDVozVPRfEtecOGCR659K+zxLKEYiNTurSnI=; b=ZVyBiA9LDpqPSNtwJqMcXCGFJQQbh/QPpV70fpQWEehizxAhMa+lDnEld8hzrIHUiW XSck4i/I03Y8CgPDwYTB5CSXWgRcTUx5a8+w0IRu3lPfNGxbMRNDjAqwc6EIf3ugN2UY osJfTXRNoz7sUNbOxvtP52AR2Udm+NNDFh0Hw6JQvl2oxrRzJkJaduj7l0ZUWDIURdvr MISHr/lPjdQoJQuJzEmSt36SVb3R84Wf5+RnO4anw9UNwd6/5Zw+5GdNsEy5hyzXpQpE Iq9bbdAixvLBIVyUBIDLUvTS/IUaTjp22g7zFMWMuupEb0Z13zmBBeoexRr175WML3fW 3QgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Fp6qne4sDVozVPRfEtecOGCR659K+zxLKEYiNTurSnI=; b=YKnVyHdCFHctejQNhi2J8JmTEZ0wynK8sOPO6ejRNqBgTRvi8OY3C6wPkTbC1ZyNXM OU0czOPbAj/el6jQnMda3yy5vJBfOZeCdoEhs+Xvb50mWATByJz+ne8PEAqGKLz+4//K FjbEOduVUwmiJvnMgJSkG+GrQpUF14Uu4eKD6c/6X0mNZZcI7/EVDE23D7DeY22gEIJR AXqCyNpfKXenh/0OkRj/B09c/5uNNLJPuUqssUNkQ7Y5hHBFSgSHRv1c00msA+ZI8ze5 +epSw2PQquGmN7c25xeC/x4RoCur0mtd6ZtwkCVyVYFYq93XxArg2rps7p4ozNiPDCtH DkJg== X-Gm-Message-State: AOAM530LYPvW0zxe6JwF3cXcHxwndbb1e1k729lKAL+pAb/CdD7+ie4z ITarc7rKun68mjA1OiRb/BBMjfn/mhQjJnr/NI4= X-Google-Smtp-Source: ABdhPJwsJO48P6PJG+xUjw4p6OCbJUvqtXYzIhA+ZyYdtla4/O+o1MfL05vK6QDt3BizGgKMT369eY5WZOWzYtYDxTA= X-Received: by 2002:a67:f588:: with SMTP id i8mr3701186vso.40.1632813355654; Tue, 28 Sep 2021 00:15:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?5Y+w6L+Q5pa5?= Date: Tue, 28 Sep 2021 15:15:44 +0800 Message-ID: Subject: Re: [BUG] The usage of memory cgroup is not consistent with processes when using THP To: Yang Shi Cc: Johannes Weiner , Hugh Dickins , Tejun Heo , Cgroups , Linux MM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 6F02D10000AB X-Stat-Signature: se9xa1nupbrtmf8ak9wqc61x7ikkz8t7 Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ZVyBiA9L; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf12.hostedemail.com: domain of yunfangtai09@gmail.com designates 209.85.217.48 as permitted sender) smtp.mailfrom=yunfangtai09@gmail.com X-HE-Tag: 1632813356-406831 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: Yang Shi =E4=BA=8E2021=E5=B9=B49=E6=9C=8828=E6=97=A5= =E5=91=A8=E4=BA=8C =E4=B8=8A=E5=8D=881:28=E5=86=99=E9=81=93=EF=BC=9A > IMHO I don't think this is a bug. The disparity reflects the > difference in how the page life cycle is viewed between process and > cgroup. The usage of process comes from the rss_counter of mm. It > tracks the per-process mapped memory usage. So it is updated once the > page is zapped. > > But from the point of cgroup, the page is charged when it is allocated > and uncharged when it is freed. The page may be zapped by one process, > but there might be other users pin the page to prevent it from being > freed. The pin may be very transient or may be indefinite. THP is one > of the pins. It is gone when the THP is split, but the split may > happen a long time after the page is zapped due to deferred split. Thank you for reply. I agree that it reflects the difference between process and cgroup. The memory usage of cgroup is usually used to indicate the memory usage of the container. It can be used to avoid the OOM and etc. The disparity will cause that the memory usage of containers with the same processes are randomly different (we found more than 30GB different). It is hard to manage them. Of course, disable THP is a way to solve it. Can it have another way to solve it ?