On 1/3/19 11:18 PM, Shakeel Butt wrote:
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.
Nothing, it it just a question of implementing it.
I'll try to look at it.
--
Manfred
