* [PATCH] mm/memcontrol: add memory.peak in cgroup root
@ 2023-02-21 14:34 Matthew Chae
2023-02-21 15:07 ` Michal Hocko
2023-02-23 14:20 ` Michal Koutný
0 siblings, 2 replies; 4+ messages in thread
From: Matthew Chae @ 2023-02-21 14:34 UTC (permalink / raw)
To: Johannes Weiner, Michal Hocko, Roman Gushchin, Shakeel Butt,
Andrew Morton
Cc: kernel, christopher.wong, Matthew Chae, Muchun Song, cgroups,
linux-mm, linux-kernel
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 <christopher.wong@axis.com>
Signed-off-by: Christopher Wong <christopher.wong@axis.com>
Signed-off-by: Matthew Chae <matthew.chae@axis.com>
---
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,
},
{
--
2.20.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] mm/memcontrol: add memory.peak in cgroup root
2023-02-21 14:34 [PATCH] mm/memcontrol: add memory.peak in cgroup root Matthew Chae
@ 2023-02-21 15:07 ` Michal Hocko
[not found] ` <DB4PR02MB93344BAA949FA7E25E298C90FEA59@DB4PR02MB9334.eurprd02.prod.outlook.com>
2023-02-23 14:20 ` Michal Koutný
1 sibling, 1 reply; 4+ messages in thread
From: Michal Hocko @ 2023-02-21 15:07 UTC (permalink / raw)
To: Matthew Chae
Cc: Johannes Weiner, Roman Gushchin, Shakeel Butt, Andrew Morton,
kernel, christopher.wong, Muchun Song, cgroups, linux-mm,
linux-kernel
On Tue 21-02-23 15:34:20, Matthew Chae wrote:
> 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.
The problem I can see is that the root's peak value doesn't really
represent the system peak memory usage because it only reflects memcg
accounted memory. So there is plenty of memory consumption which is not
covered. On top of that a lot of memory contributed to the root memcg is
not accounted at all (see try_charge and its callers) so the cumulative
hierarchical value is incomplete and I believe misleading as well.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] mm/memcontrol: add memory.peak in cgroup root
2023-02-21 14:34 [PATCH] mm/memcontrol: add memory.peak in cgroup root Matthew Chae
2023-02-21 15:07 ` Michal Hocko
@ 2023-02-23 14:20 ` Michal Koutný
1 sibling, 0 replies; 4+ messages in thread
From: Michal Koutný @ 2023-02-23 14:20 UTC (permalink / raw)
To: Matthew Chae
Cc: Johannes Weiner, Michal Hocko, Roman Gushchin, Shakeel Butt,
Andrew Morton, kernel, christopher.wong, Muchun Song, cgroups,
linux-mm, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
Hello Matthew.
On Tue, Feb 21, 2023 at 03:34:20PM +0100, Matthew Chae <matthew.chae@axis.com> wrote:
> 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.
The memory.peak value is useful as a calibration insight when you want to
configure memcg limit.
But there is no global (memcg) limit on memory. So what would be this
(not clearly) defined value good for? Or better then userspace sampling
of chosen available metric?
Thanks,
Michal
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-02-23 14:21 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-21 14:34 [PATCH] mm/memcontrol: add memory.peak in cgroup root Matthew Chae
2023-02-21 15:07 ` Michal Hocko
[not found] ` <DB4PR02MB93344BAA949FA7E25E298C90FEA59@DB4PR02MB9334.eurprd02.prod.outlook.com>
2023-02-21 16:16 ` Sv: " Michal Hocko
2023-02-23 14:20 ` Michal Koutný
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).