From: Joerg Vehlow <lkml@jv-coder.de>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] memcg: memcg_subgroup_charge.sh: Fix the parent memory limit
Date: Mon, 8 Mar 2021 09:07:15 +0100 [thread overview]
Message-ID: <a47ecbd7-ba4a-ff2c-ead9-e731040cb845@jv-coder.de> (raw)
In-Reply-To: <20210305222714.257839-1-msys.mizuma@gmail.com>
Hi,
On 3/5/2021 11:27 PM, Masayoshi Mizuma wrote:
> From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
>
> memcg_subgroup_charge.sh fails on v5.9 and later kernel.
> That's because memory.limit_in_bytes isn't set the suitable value
> so mem_process is killed by OOM accidentally.
>
> The memory.limit_in_bytes is now wrong value because commit
> 3e38e0aaca9e ("mm: memcg: charge memcg percpu memory to the parent cgroup")
> changed the charging memory usage. The percpu memory, which is
> needed to create the subgroup, is charged to the parent's usage.
>
> Since we can get the amount of the percpu memory as memory.usage_in_bytes
> after the subgroup is created, extend the limit to limit_in_bytes + usage_in_bytes.
Sounds reasonable, I guess the test always fails on 5.9?
But the problem is, this test also fails on older kernels sometimes.
When I looked at this the last time, I thought it was because sometimes
the kernel requires new pages for the page table and that is also taken
into account for the memory limit.
I still don't know why the test even sets a limit for the parent group
and would vote for completely removing the memory setting on the parent.
J?rg
next prev parent reply other threads:[~2021-03-08 8:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-05 22:27 [LTP] [PATCH] memcg: memcg_subgroup_charge.sh: Fix the parent memory limit Masayoshi Mizuma
2021-03-08 8:07 ` Joerg Vehlow [this message]
2021-09-14 8:34 ` [LTP] [PATCH] memcg_subgroup_charge: Remove limiting of parent Richard Palethorpe
2021-09-14 8:34 ` Richard Palethorpe via ltp
2021-09-14 12:32 ` Cyril Hrubis
2021-09-14 12:32 ` Cyril Hrubis
2021-09-20 5:20 ` Joerg Vehlow
2021-09-21 15:00 ` Cyril Hrubis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a47ecbd7-ba4a-ff2c-ead9-e731040cb845@jv-coder.de \
--to=lkml@jv-coder.de \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.