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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4A4D4C3DA59 for ; Tue, 16 Jul 2024 12:48:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BC45D6B0096; Tue, 16 Jul 2024 08:48:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B74556B0098; Tue, 16 Jul 2024 08:48:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3BF56B009C; Tue, 16 Jul 2024 08:48:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 7E6A16B0096 for ; Tue, 16 Jul 2024 08:48:15 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2C083121106 for ; Tue, 16 Jul 2024 12:48:14 +0000 (UTC) X-FDA: 82345593708.29.EA2E72A Received: from mail-il1-f175.google.com (mail-il1-f175.google.com [209.85.166.175]) by imf12.hostedemail.com (Postfix) with ESMTP id 328E04000B for ; Tue, 16 Jul 2024 12:48:12 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=vimeo.com header.s=google header.b=jMCbDkG7; spf=pass (imf12.hostedemail.com: domain of davidf@vimeo.com designates 209.85.166.175 as permitted sender) smtp.mailfrom=davidf@vimeo.com; dmarc=pass (policy=reject) header.from=vimeo.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721134072; 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:in-reply-to:references:references:dkim-signature; bh=P1Inyqx4hFkx/0tFCh/+I7H14Me6CfgzvTl8nNfgBkM=; b=wyjVw41ytOdtVV9QuK3dlflaNr/ZI2bRnKoepdWNVafrS03fEEPkn2Aci11wVdtIoq8/wk MHF0obaoFdtoJ9tOm/yv3vdsLBt/51Dc091OVv6osUZyeD5TA76Oe4MYVXj52EJp2YdJN5 TBFEEo0czFdO6voBB+qXD5OjcudbtE4= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=vimeo.com header.s=google header.b=jMCbDkG7; spf=pass (imf12.hostedemail.com: domain of davidf@vimeo.com designates 209.85.166.175 as permitted sender) smtp.mailfrom=davidf@vimeo.com; dmarc=pass (policy=reject) header.from=vimeo.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721134072; a=rsa-sha256; cv=none; b=hpHeCOcPgFgswdboDKWVBwnbFJ+cRS5PUuHUyro40OpPvDX4wvtmV9674nE4ysoZuIMqeD GhrQheIilusLOy0ehref+/7i8LBE/ggjXfaeZNVMLYL4KoFIiP7ajUZxTiimZiAwI+cta3 9E4m+neRtv5G8HRiZXSoK2R7FMrOhuM= Received: by mail-il1-f175.google.com with SMTP id e9e14a558f8ab-3738690172eso22213335ab.1 for ; Tue, 16 Jul 2024 05:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimeo.com; s=google; t=1721134091; x=1721738891; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=P1Inyqx4hFkx/0tFCh/+I7H14Me6CfgzvTl8nNfgBkM=; b=jMCbDkG7QCt6Vt3i4B9QdjE1qzwuns3o/7nY8kel5dwmj05xSEC/tG0+6wMnJyMd8H lgyqnNKHxnaNg7mwadSWE+wnyiRNGCuCFbj35kgg/EPI54S0BHEMCXhhy6JlILZlPnDH RKV33PqcowEULdrNsdwfuqqSa9Yt43gf/KKRw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721134091; x=1721738891; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=P1Inyqx4hFkx/0tFCh/+I7H14Me6CfgzvTl8nNfgBkM=; b=WoqNYNR583qmiXNu5IB3NahpnsyW4N2kxud9JfHDjgTHnhMqYSLx1EJkDKMOpY/GaJ LasKcFSqvB9e5moDXan65Z4J+tl5WPPpiKv9eGoDFynY6B4fIs/r5lY7K7OqZHfmSfsd doHYY5GARC+6FVPZaeMua2hmmU6uyNuk0LLK9c3RdqG+kLYeXfN5kt00ZOyr+4CAVYUn fhIJ1KQ1d0WnXcWqHBx1nnt8xYIcTEUjyBEFHRaqlG6r8jlSDBsG91jOlNnFWXxjem0A jR1EhhgESxej8Bt2dwa34PcRyf+Qsy3habpJu+Thl3SqQgHJwdbq66l8jeRrETI8UwUQ jX2A== X-Forwarded-Encrypted: i=1; AJvYcCWf6M5ie8lvhq+4DKAuC86YKweHshxQODShXVWlRcjOzGLLTnq5LphhChzCXq5gq6HL7zQyRud5ZzSquSKWAYIF/nM= X-Gm-Message-State: AOJu0YwnNPBO36Haf4+yaVxeKWVCuJBYHLdMr/9miPBahdlfhN5QJ+qH ZlCrWis9+30CcDtYZNBVq/94GprRUFpMyGpDIcl/kZnVcVNdwWDyNfTDRKdebCXYzYdbBPTeThS EMAbBC6yus5fVx98mYgFIYQy2lgOW2u7GmPNoPw== X-Google-Smtp-Source: AGHT+IE+pFu/o/3E1h/NjccXjXKorJXCuoVzp+n3829K8lRaP9muWQ8Ln8LjOfnsMtjH9SYYlvTwLasgQhYmPNQq150= X-Received: by 2002:a05:6e02:b44:b0:382:6913:236 with SMTP id e9e14a558f8ab-393d1fd87e6mr26539445ab.18.1721134090976; Tue, 16 Jul 2024 05:48:10 -0700 (PDT) MIME-Version: 1.0 References: <20240715203625.1462309-1-davidf@vimeo.com> <20240715203625.1462309-2-davidf@vimeo.com> In-Reply-To: From: David Finkel Date: Tue, 16 Jul 2024 08:47:59 -0400 Message-ID: Subject: Re: [PATCH] mm, memcg: cg2 memory{.swap,}.peak write handlers To: Michal Hocko Cc: Muchun Song , Andrew Morton , core-services@vimeo.com, Jonathan Corbet , Roman Gushchin , Shuah Khan , Johannes Weiner , Tejun Heo , Zefan Li , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Shakeel Butt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 328E04000B X-Stat-Signature: pf86wrre7qx5jj9w1ehh433stwrgrj8w X-Rspam-User: X-HE-Tag: 1721134092-909177 X-HE-Meta: U2FsdGVkX1+3pmR3VIm08COB5u3ITR3O5Uw+uRLGw1OOJ2eBGM3ROLO3tv29GX8l1nYSxKpn7j9kt0/p20vujsPWqZG0FbYDh9wUxb632qwQpnQY2c7djhq/+gnyuBGbish7njcegQhU6M0fNjyn42WTj6Y3+niLJ06BonG8a0To4z4DXomFLMsIheLJSc1kEJwmdMSX9kKDmREYFds59bs1gzGamWrIq8xfSTs1QHsafcTgHOeE3hKi/4Zc8IoFn5Y/O9VZvZS48927Ju0VFYmaqPFl2gMBoLPQB8WTh1EQa5i+tcc9OdnF5fq0Ajhqy/Hhsm7OfFj92nIBDK+zWJYg2LerkfJQIAzwEM9HFgJk0MH4LYIsoNpWcQ39iR4s3tdgpPqDY/USlVldciR8fc6kiYVnr14BVA+4hex5QpqJH4HcIdmZtTawahwtxnP6aXnEWQSvWBGEXI/WzKEiRsqOAI/bKFjlv3UsyA2hXjDndYM7jPedXx37Mc5U9jO3NgMm+XfeKGnCPAVUKJsCa5Hu/mRDT1ifDJiz7UMZZ+Gq9J5VoUzlSKr6eLYUIVdOCT9mPCL1yEZ3UdkXn1IkqCj0REWk4gLl2JqPkd40lST8zPee7h7nSpcF/qAlNitUEbCZgq8LxK2jfAplN250f3cK2/rfsltN9AHY6zgIimGNq/tTdy7ZYCDawd1xOBzEEygvm9q1tvPBSv6Rrsoy72Me0hKabOHY0YGXCurzhpPAnWHf6xpeyuLcR/X6BZdf6iZ4vzZeEsGU6gi1r42ukexQshIFVzcYy51nRrj4iA70P1Zw8F7b+CaNW1/WfSubcb1dORF7sGwsZInlK+0bE8BbfamDt+YJAT0HnVVkaNqFe3XJmsxncTxhpQENlAkrEh/0WkC2SD9ZsQgNePtf9rqSPlIV3EbDnMpjQtTpsKSq8lVdD1cnFLVue4vuXZ7IIutxAub8w55n/ftTV3q hamQ61IR 7p2rGkS+rdf+HlGTofLD0dsbx5603QJUIeGxzQ/n6ijZHb48XmrYjQ24g/GI2tu+JwLzRgb/yGFYorvNPvCUwO52VD8MsAHhqY37SdAApmJjZKllR4WOYv9BJXFoWTj3PF0PC0548JeNTLXf1obSzqPITCJZm6rbC58P8COp0yDeZPuQwPKsvqvqWlm0F5/X3KbTeNxmU29100/jg/OTet7jPoWXfzrw6kZ8U2D6p4I/+j2LUw8MRuIvb6w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000017, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jul 16, 2024 at 3:20=E2=80=AFAM Michal Hocko wrot= e: > > On Mon 15-07-24 16:46:36, David Finkel wrote: > > > On Mon, Jul 15, 2024 at 4:38=E2=80=AFPM David Finkel wrote: > > > > > > > > Other mechanisms for querying the peak memory usage of either a pro= cess > > > > or v1 memory cgroup allow for resetting the high watermark. Restore > > > > parity with those mechanisms. > > > > > > > > For example: > > > > - Any write to memory.max_usage_in_bytes in a cgroup v1 mount rese= ts > > > > the high watermark. > > > > - writing "5" to the clear_refs pseudo-file in a processes's proc > > > > directory resets the peak RSS. > > > > > > > > This change copies the cgroup v1 behavior so any write to the > > > > memory.peak and memory.swap.peak pseudo-files reset the high waterm= ark > > > > to the current usage. > > > > > > > > This behavior is particularly useful for work scheduling systems th= at > > > > need to track memory usage of worker processes/cgroups per-work-ite= m. > > > > Since memory can't be squeezed like CPU can (the OOM-killer has > > > > opinions), > > I do not understand the OOM-killer reference here. Why does it matter? > Could you explain please? Sure, we're attempting to bin-packing work based on past items of the same = type. With CPU, we can provision for the mean CPU-time per-wall-time to get a lose "cores" concept that we use for binpacking. With CPU, if we end up with a bit of contention, everything just gets a bit slower while the schedule arbitrates among cgrou= ps. However, with memory, you only have so much physical memory for the outer m= emcg. If we pack things too tightly on memory, the OOM-killer is going to kill something to free up memory. In some cases that's fine, but provisioning fo= r the peak memory for that "type" of work-item mostly avoids this issue. My apologies. I should have reworded this sentence before resending. (there was a question about it last time, too) > > > > > these systems need to track the peak memory usage to compute > > > > system/container fullness when binpacking workitems. > > Could you elaborate some more on how you are using this please? I expect > you recycle memcgs for different runs of workers and reset peak > consumptions before a new run and record it after it is done. The thing > which is not really clear to me is how the peak value really helps if it > can vary a lot among different runs. But maybe I misunderstand. > That's mostly correct. The workers are long-lived and will handle many work-items over their lifetimes (to amortize startup overheads). The particular system that uses this classifies work in "queues", which can be loosely assumed to use the same resources between runs, since they're doing similar work. To mitigate the effect of outliers, we take a high quantile of the peak mem= ory consumed by work items within a queue when estimating the memory dimension to binpack future work-items. > > > > > > > > Signed-off-by: David Finkel > > > > --- > > > > Documentation/admin-guide/cgroup-v2.rst | 20 +++--- > > > > mm/memcontrol.c | 23 ++++++ > > > > .../selftests/cgroup/test_memcontrol.c | 72 +++++++++++++++= +--- > > > > 3 files changed, 99 insertions(+), 16 deletions(-) > > > > > > > > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentatio= n/admin-guide/cgroup-v2.rst > > > > index 8fbb0519d556..201d8e5d9f82 100644 > > > > --- a/Documentation/admin-guide/cgroup-v2.rst > > > > +++ b/Documentation/admin-guide/cgroup-v2.rst > > > > @@ -1322,11 +1322,13 @@ PAGE_SIZE multiple when read back. > > > > reclaim induced by memory.reclaim. > > > > > > > > memory.peak > > > > - A read-only single value file which exists on non-root > > > > - cgroups. > > > > + A read-write single value file which exists on non-root cgr= oups. > > > > + > > > > + The max memory usage recorded for the cgroup and its descen= dants since > > > > + either the creation of the cgroup or the most recent reset. > > > > > > > > - The max memory usage recorded for the cgroup and its > > > > - descendants since the creation of the cgroup. > > > > + Any non-empty write to this file resets it to the current m= emory usage. > > > > + All content written is completely ignored. > > > > > > > > memory.oom.group > > > > A read-write single value file which exists on non-root > > > > @@ -1652,11 +1654,13 @@ PAGE_SIZE multiple when read back. > > > > Healthy workloads are not expected to reach this limit. > > > > > > > > memory.swap.peak > > > > - A read-only single value file which exists on non-root > > > > - cgroups. > > > > + A read-write single value file which exists on non-root cgr= oups. > > > > + > > > > + The max swap usage recorded for the cgroup and its descenda= nts since > > > > + the creation of the cgroup or the most recent reset. > > > > > > > > - The max swap usage recorded for the cgroup and its > > > > - descendants since the creation of the cgroup. > > > > + Any non-empty write to this file resets it to the current s= wap usage. > > > > + All content written is completely ignored. > > > > > > > > memory.swap.max > > > > A read-write single value file which exists on non-root > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > > > index 8f2f1bb18c9c..abfa547615d6 100644 > > > > --- a/mm/memcontrol.c > > > > +++ b/mm/memcontrol.c > > > > @@ -25,6 +25,7 @@ > > > > * Copyright (C) 2020 Alibaba, Inc, Alex Shi > > > > */ > > > > > > > > +#include > > > > #include > > > > #include > > > > #include > > > > @@ -6915,6 +6916,16 @@ static u64 memory_peak_read(struct cgroup_su= bsys_state *css, > > > > return (u64)memcg->memory.watermark * PAGE_SIZE; > > > > } > > > > > > > > +static ssize_t memory_peak_write(struct kernfs_open_file *of, > > > > + char *buf, size_t nbytes, loff_t o= ff) > > > > +{ > > > > + struct mem_cgroup *memcg =3D mem_cgroup_from_css(of_css(of)= ); > > > > + > > > > + page_counter_reset_watermark(&memcg->memory); > > > > + > > > > + return nbytes; > > > > +} > > > > + > > > > static int memory_min_show(struct seq_file *m, void *v) > > > > { > > > > return seq_puts_memcg_tunable(m, > > > > @@ -7232,6 +7243,7 @@ static struct cftype memory_files[] =3D { > > > > .name =3D "peak", > > > > .flags =3D CFTYPE_NOT_ON_ROOT, > > > > .read_u64 =3D memory_peak_read, > > > > + .write =3D memory_peak_write, > > > > }, > > > > { > > > > .name =3D "min", > > > > @@ -8201,6 +8213,16 @@ static u64 swap_peak_read(struct cgroup_subs= ys_state *css, > > > > return (u64)memcg->swap.watermark * PAGE_SIZE; > > > > } > > > > > > > > +static ssize_t swap_peak_write(struct kernfs_open_file *of, > > > > + char *buf, size_t nbytes, loff_t o= ff) > > > > +{ > > > > + struct mem_cgroup *memcg =3D mem_cgroup_from_css(of_css(of)= ); > > > > + > > > > + page_counter_reset_watermark(&memcg->swap); > > > > + > > > > + return nbytes; > > > > +} > > > > + > > > > static int swap_high_show(struct seq_file *m, void *v) > > > > { > > > > return seq_puts_memcg_tunable(m, > > > > @@ -8283,6 +8305,7 @@ static struct cftype swap_files[] =3D { > > > > .name =3D "swap.peak", > > > > .flags =3D CFTYPE_NOT_ON_ROOT, > > > > .read_u64 =3D swap_peak_read, > > > > + .write =3D swap_peak_write, > > > > }, > > > > { > > > > .name =3D "swap.events", > > > > diff --git a/tools/testing/selftests/cgroup/test_memcontrol.c b/too= ls/testing/selftests/cgroup/test_memcontrol.c > > > > index 41ae8047b889..681972de673b 100644 > > > > --- a/tools/testing/selftests/cgroup/test_memcontrol.c > > > > +++ b/tools/testing/selftests/cgroup/test_memcontrol.c > > > > @@ -161,12 +161,12 @@ static int alloc_pagecache_50M_check(const ch= ar *cgroup, void *arg) > > > > /* > > > > * This test create a memory cgroup, allocates > > > > * some anonymous memory and some pagecache > > > > - * and check memory.current and some memory.stat values. > > > > + * and checks memory.current, memory.peak, and some memory.stat va= lues. > > > > */ > > > > -static int test_memcg_current(const char *root) > > > > +static int test_memcg_current_peak(const char *root) > > > > { > > > > int ret =3D KSFT_FAIL; > > > > - long current; > > > > + long current, peak, peak_reset; > > > > char *memcg; > > > > > > > > memcg =3D cg_name(root, "memcg_test"); > > > > @@ -180,12 +180,32 @@ static int test_memcg_current(const char *roo= t) > > > > if (current !=3D 0) > > > > goto cleanup; > > > > > > > > + peak =3D cg_read_long(memcg, "memory.peak"); > > > > + if (peak !=3D 0) > > > > + goto cleanup; > > > > + > > > > if (cg_run(memcg, alloc_anon_50M_check, NULL)) > > > > goto cleanup; > > > > > > > > + peak =3D cg_read_long(memcg, "memory.peak"); > > > > + if (peak < MB(50)) > > > > + goto cleanup; > > > > + > > > > + peak_reset =3D cg_write(memcg, "memory.peak", "\n"); > > > > + if (peak_reset !=3D 0) > > > > + goto cleanup; > > > > + > > > > + peak =3D cg_read_long(memcg, "memory.peak"); > > > > + if (peak > MB(30)) > > > > + goto cleanup; > > > > + > > > > if (cg_run(memcg, alloc_pagecache_50M_check, NULL)) > > > > goto cleanup; > > > > > > > > + peak =3D cg_read_long(memcg, "memory.peak"); > > > > + if (peak < MB(50)) > > > > + goto cleanup; > > > > + > > > > ret =3D KSFT_PASS; > > > > > > > > cleanup: > > > > @@ -817,13 +837,14 @@ static int alloc_anon_50M_check_swap(const ch= ar *cgroup, void *arg) > > > > > > > > /* > > > > * This test checks that memory.swap.max limits the amount of > > > > - * anonymous memory which can be swapped out. > > > > + * anonymous memory which can be swapped out. Additionally, it ver= ifies that > > > > + * memory.swap.peak reflects the high watermark and can be reset. > > > > */ > > > > -static int test_memcg_swap_max(const char *root) > > > > +static int test_memcg_swap_max_peak(const char *root) > > > > { > > > > int ret =3D KSFT_FAIL; > > > > char *memcg; > > > > - long max; > > > > + long max, peak; > > > > > > > > if (!is_swap_enabled()) > > > > return KSFT_SKIP; > > > > @@ -840,6 +861,12 @@ static int test_memcg_swap_max(const char *roo= t) > > > > goto cleanup; > > > > } > > > > > > > > + if (cg_read_long(memcg, "memory.swap.peak")) > > > > + goto cleanup; > > > > + > > > > + if (cg_read_long(memcg, "memory.peak")) > > > > + goto cleanup; > > > > + > > > > if (cg_read_strcmp(memcg, "memory.max", "max\n")) > > > > goto cleanup; > > > > > > > > @@ -862,6 +889,27 @@ static int test_memcg_swap_max(const char *roo= t) > > > > if (cg_read_key_long(memcg, "memory.events", "oom_kill ") != =3D 1) > > > > goto cleanup; > > > > > > > > + peak =3D cg_read_long(memcg, "memory.peak"); > > > > + if (peak < MB(29)) > > > > + goto cleanup; > > > > + > > > > + peak =3D cg_read_long(memcg, "memory.swap.peak"); > > > > + if (peak < MB(29)) > > > > + goto cleanup; > > > > + > > > > + if (cg_write(memcg, "memory.swap.peak", "\n")) > > > > + goto cleanup; > > > > + > > > > + if (cg_read_long(memcg, "memory.swap.peak") > MB(10)) > > > > + goto cleanup; > > > > + > > > > + > > > > + if (cg_write(memcg, "memory.peak", "\n")) > > > > + goto cleanup; > > > > + > > > > + if (cg_read_long(memcg, "memory.peak")) > > > > + goto cleanup; > > > > + > > > > if (cg_run(memcg, alloc_anon_50M_check_swap, (void *)MB(30)= )) > > > > goto cleanup; > > > > > > > > @@ -869,6 +917,14 @@ static int test_memcg_swap_max(const char *roo= t) > > > > if (max <=3D 0) > > > > goto cleanup; > > > > > > > > + peak =3D cg_read_long(memcg, "memory.peak"); > > > > + if (peak < MB(29)) > > > > + goto cleanup; > > > > + > > > > + peak =3D cg_read_long(memcg, "memory.swap.peak"); > > > > + if (peak < MB(19)) > > > > + goto cleanup; > > > > + > > > > ret =3D KSFT_PASS; > > > > > > > > cleanup: > > > > @@ -1295,7 +1351,7 @@ struct memcg_test { > > > > const char *name; > > > > } tests[] =3D { > > > > T(test_memcg_subtree_control), > > > > - T(test_memcg_current), > > > > + T(test_memcg_current_peak), > > > > T(test_memcg_min), > > > > T(test_memcg_low), > > > > T(test_memcg_high), > > > > @@ -1303,7 +1359,7 @@ struct memcg_test { > > > > T(test_memcg_max), > > > > T(test_memcg_reclaim), > > > > T(test_memcg_oom_events), > > > > - T(test_memcg_swap_max), > > > > + T(test_memcg_swap_max_peak), > > > > T(test_memcg_sock), > > > > T(test_memcg_oom_group_leaf_events), > > > > T(test_memcg_oom_group_parent_events), > > > > -- > > > > 2.40.1 > > > > > > > > > > > > > -- > > > David Finkel > > > Senior Principal Software Engineer, Core Services > > > > > > > > -- > > David Finkel > > Senior Principal Software Engineer, Core Services > > -- > Michal Hocko > SUSE Labs Thanks! --=20 David Finkel Senior Principal Software Engineer, Core Services