Hi Manfred, On Sun, Dec 23, 2018 at 4:26 AM Manfred Spraul <manf...@colorfullife.com> wrote: > > Hello Dmitry, > > On 12/23/18 10:57 AM, Dmitry Vyukov wrote: > > > > I can reproduce this infinite memory consumption with the C program: > > https://gist.githubusercontent.com/dvyukov/03ec54b3429ade16fa07bf8b2379aff3/raw/ae4f654e279810de2505e8fa41b73dc1d77778e6/gistfile1.txt > > > > But this is working as intended, right? It just creates infinite > > number of large semaphore sets, which reasonably consumes infinite > > amount of memory. > > Except that it also violates the memcg bound and a process can have > > effectively unlimited amount of such "drum memory" in semaphores. > > Yes, this is as intended: > > If you call semget(), then you can use memory, up to the limits in > /proc/sys/kernel/sem. > > Memcg is not taken into account, an admin must set /proc/sys/kernel/sem. > > The default are "infinite amount of memory allowed", as this is the most > sane default: We had a logic that tried to autotune (i.e.: a new > namespace "inherits" a fraction of the parent namespaces memory limits), > but this we more or less always wrong. > >
What's the disadvantage of setting the limits in /proc/sys/kernel/sem high and let the task's memcg limits the number of semaphore a process can create? Please note that the memory underlying shmget and msgget is already accounted to memcg. thanks, Shakeel
