[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <iedonwzoqj75yeaykgovdufi53cu3ddsrqfhdfui5kgwlal6pq@mdeue6pc6byz>
Date: Fri, 2 Aug 2024 00:58:03 +0200
From: Michal Koutný <mkoutny@...e.com>
To: Lance Yang <ioworker0@...il.com>
Cc: "Vlastimil Babka (SUSE)" <vbabka@...nel.org>,
akpm@...ux-foundation.org, 21cnbao@...il.com, ryan.roberts@....com, david@...hat.com,
shy828301@...il.com, ziy@...dia.com, libang.li@...group.com,
baolin.wang@...ux.alibaba.com, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Johannes Weiner <hannes@...xchg.org>, Michal Hocko <mhocko@...nel.org>,
Roman Gushchin <roman.gushchin@...ux.dev>, Shakeel Butt <shakeel.butt@...ux.dev>,
Muchun Song <muchun.song@...ux.dev>, Cgroups <cgroups@...r.kernel.org>
Subject: Re: [BUG] mm/cgroupv2: memory.min may lead to an OOM error
Hello.
On Thu, Aug 01, 2024 at 07:40:10PM GMT, Lance Yang <ioworker0@...il.com> wrote:
> However, if the child cgroup doesn't exist and we add a process to the 'test'
> cgroup, then attempt to create a large file(2GB) using dd, we won't encounter
> an OOM error; everything works as expected.
That's due to the way how effective protections are calculated, see [1].
If reclaim target is cgroup T, then it won't enjoy protection configured
on itself, whereas the child of T is subject of ancestral reclaim hence
the protection applies.
That would mean that in your 1st demo, it is test/memory.max that
triggers reclaim and then failure to reclaim from test/test-child causes
OOM in test.
That's interesting since the (same) limit of test-child/memory.max
should be evaluated first. I guess it is in your example there are
actually two parallel processes (1321 and 1324) so some charges may
randomly propagate to the upper test/memory.max limit.
As explained above, the 2nd demo has same reclaim target but due to no
nesting, protection is moot.
I believe you could reproduce with merely
test/memory.max
test-child/memory.min
> Hmm... I'm a bit confused about that.
I agree, the calculation of effective protection wrt reclaim target can
be confusing.
The effects you see are documented for memory.min:
> Putting more memory than generally available under this
> protection is discouraged and may lead to constant OOMs.
HTH,
Michal
[1] https://lore.kernel.org/all/20200729140537.13345-2-mkoutny@suse.com/
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists