All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.