From patchwork Tue Feb 21 14:34:20 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Chae X-Patchwork-Id: 13148000 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 93CE3C636D7 for ; Tue, 21 Feb 2023 14:34:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F9A56B0075; Tue, 21 Feb 2023 09:34:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0AA226B0078; Tue, 21 Feb 2023 09:34:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDBD36B007B; Tue, 21 Feb 2023 09:34:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id DE9D86B0075 for ; Tue, 21 Feb 2023 09:34:31 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id ACBCCA0607 for ; Tue, 21 Feb 2023 14:34:31 +0000 (UTC) X-FDA: 80491544742.19.2F865F8 Received: from smtp1.axis.com (smtp1.axis.com [195.60.68.17]) by imf16.hostedemail.com (Postfix) with ESMTP id CF50F180007 for ; Tue, 21 Feb 2023 14:34:28 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=axis.com header.s=axis-central1 header.b=X+cAWgoV; dmarc=pass (policy=none) header.from=axis.com; spf=pass (imf16.hostedemail.com: domain of Matthew.Chae@axis.com designates 195.60.68.17 as permitted sender) smtp.mailfrom=Matthew.Chae@axis.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676990069; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=e0/vm795K+DdiwKlFn5UN5He4cprPggTB4iadCKSttU=; b=gweM/VTw9JlR6r6dnscDnTNkNnr5as8UiSzlwrbbUeOydmeNLfw73HnLw+w7F4uQpRAajy FD6gp2NVaEFdEhz9LDpZ5V/13HhNueMTR4sTb91hUAAJyCqLOp2TpAc/yEPcy6gZss8off KGdEIPs0/rxsXLn1EmgSpHPQXed0eGs= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=axis.com header.s=axis-central1 header.b=X+cAWgoV; dmarc=pass (policy=none) header.from=axis.com; spf=pass (imf16.hostedemail.com: domain of Matthew.Chae@axis.com designates 195.60.68.17 as permitted sender) smtp.mailfrom=Matthew.Chae@axis.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676990069; a=rsa-sha256; cv=none; b=iTEAf1naWyLpSs0J+BQq0nhzGltCR0nl1qODvxrDubbqooWEILSuaoa8EeecFnkrT1xzy8 tC25uZb7RfijfyZ3S96GnzWxA2HE0H1pICY7AXaRfTtctMJiZLHRYiAFGRVpkysmFySZR9 sOfm/doMahXlbqn+YJ0niN/XJzoCfvw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axis.com; q=dns/txt; s=axis-central1; t=1676990069; x=1708526069; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=e0/vm795K+DdiwKlFn5UN5He4cprPggTB4iadCKSttU=; b=X+cAWgoVxbrZjYymvQm8d2+vIlZjBM7MU9zBHxg5SzNM+U8lW5pPkaHR ecWMrXcV+hepTNiQCbtVUYj9qcokrOvoKZD12l56BsFuOvkPuus0pfw7B BIhTOiTaRHttezX1BwLtwkXdd7sxUwiNBiPZlhdseh/XFmIWhDeE/wdlX 3Z8Y+wCMgUjDYs7aTLIY3PeCoovYnlqSTUPQLwFhYNJi+iaH81TLkS6ja Pkn0XNn5H7HIa292iLNBNdmxEjqrIxrSsajyfoIaOY5HCCGbyyR8c+npL ceCKCXbezzFdCw5eMNVrME+8vrr5Dxx3AEV9XmAxCHGCJZosTxChFQBQK w==; From: Matthew Chae To: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Andrew Morton CC: , , Matthew Chae , Muchun Song , , , Subject: [PATCH] mm/memcontrol: add memory.peak in cgroup root Date: Tue, 21 Feb 2023 15:34:20 +0100 Message-ID: <20230221143421.10385-1-matthew.chae@axis.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: CF50F180007 X-Stat-Signature: i7cecpysux9igz7d5fhzsryg653sspdg X-HE-Tag: 1676990068-501767 X-HE-Meta: U2FsdGVkX1+UaxWb0D8a5kmNbKidsP6hbJfMLmRvKJhrN3BqWW5RHsOwYHHnkk573+WlQQxcjv20wcosn5M8/AzIRxQYI2nrVb/cSJjQVhjfM5De1V7ennmr4r/cRIGlvrBpGd3YnYTt1S+lBRAvHF6k3X9IsY+mTvcS7Q47itucAEJHoqp4lqHhmYfTjqj81cVtjh9d+2onvfCStgMdtVquXMxmjRc+N/CC0wOkhvllonlD7LOaa/JSnlYHsef5uxkFsEq4kOQ/yDIpb6KNTSz4z4UBQcxNTMKfCgLXyY6+XDz0c5/AQDOB6fDJr/0dF8zLBTIYZLbuUoHkg3XJf4SBO3F7N67apu/qRid8i6/jv8Ju5VVMkNECAFy6dl0u7dbY70n27GuDghhiuJpYnslVmwIbm+KKqLmGl9K6SPGTlkryBQB9AcXb8f8Jkh3IbFUD5wkjyv5EfoLSGP+wRIZeVI1Q3dhJvKH49SZzmo0DKVvfbPRzl4xTR6dwnqDyS3HheOLXi8Ff/vPW9RPRkN2uQcupuHjl9fBIRTNVFdZoDK3fuQ2ODxBldBKwhBovNA6RRRpA1zu5FxCoiG/+DyRSSNhtfSiO53HndydunHXYdyE5Pa11ioYZzCYFDNvcdgpMsiQQT2fF3Vas0GNweGvMfJkWwkCcQtRZE7CE1CiHngweJUQUHm5tJvycYfLX04PaV8uMYGdSApG7o5x/JivwmHHYfSybqrYUCm3swWCMMg2M77gIH3aCSiVo3XC97ixyVy/iy1EurA7CXZWTEMHB4eHxgk6PuvijoYMCP1w+DW9iZvdLXEWiES/nBZfuTbzn1dv+KAb2KOonXWBy3G12Z25y2bTFvd9eHtAD5TtE+cmIbBEUnOicL/3EQncQOnixd+pzbfhP9oXaM4SofJAnCyKj/RBMKuH6fOGQvuy6hy86DYls/ccPqwbFOlXDy/FY3kZw0qJ5oUu57gM /xKuRlZF 1pmGoW6cWTI2Jq5jMcJZZhaL6aXgWIv8fdsHGmJVWc1TTbFUKoGSqAr3iYHrYbWchEHIqfymEYYcnkgj+Puz9gDtv/voGmWLoJHXoS44upSU12BqstAI8S2O1t2fZxwvwUOE/shcz3Q1khuu2GsWepPJ4NYj5YhCv9jDGodNlLtM6hrCScUMgaomm2Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: The kernel currently doesn't provide any method to show the overall system's peak memory usage recorded. Instead, only each slice's peak memory usage recorded except for cgroup root is shown through each memory.peak. Each slice might consume their peak memory at different time. This is stored at memory.peak in each own slice. The sum of every memory.peak doesn't mean the total system's peak memory usage recorded. The sum at certain point without having a peak memory usage in their slice can have the largest value. time | slice1 | slice2 | sum ======================================= t1 | 50 | 200 | 250 --------------------------------------- t2 | 150 | 150 | 300 --------------------------------------- t3 | 180 | 20 | 200 --------------------------------------- t4 | 80 | 20 | 100 memory.peak value of slice1 is 180 and memory.peak value of slice2 is 200. Only these information are provided through memory.peak value from each slice without providing the overall system's peak memory usage. The total sum of these two value is 380, but this doesn't represent the real peak memory usage of the overall system. The peak value what we want to get is shown in t2 as 300, which doesn't have any biggest number even in one slice. Therefore the proper way to show the system's overall peak memory usage recorded needs to be provided. Hence, expose memory.peak in the cgrop root in order to allow this. Co-developed-by: Christopher Wong Signed-off-by: Christopher Wong Signed-off-by: Matthew Chae --- mm/memcontrol.c | 1 - 1 file changed, 1 deletion(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 73afff8062f9..974fc044a7e7 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -6646,7 +6646,6 @@ static struct cftype memory_files[] = { }, { .name = "peak", - .flags = CFTYPE_NOT_ON_ROOT, .read_u64 = memory_peak_read, }, {