Hi Michal, Thanks a lot for clarifying! On Fri, Aug 2, 2024 at 6:58 AM Michal Koutný <mkoutny@xxxxxxxx> wrote: > > Hello. > > On Thu, Aug 01, 2024 at 07:40:10PM GMT, Lance Yang <ioworker0@xxxxxxxxx> 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. Makes sense to me. > > 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. Ah, that clears it up. I appreciate the detailed explanation - thanks! > I believe you could reproduce with merely > > test/memory.max > test-child/memory.min Yep, I just tested it, and you're right ;) > > > 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. Thanks a lot again for your time! Lance > > HTH, > Michal > > [1] https://lore.kernel.org/all/20200729140537.13345-2-mkoutny@xxxxxxxx/
