On Tue 30-01-18 09:11:27, Florian Westphal wrote:

Michal Hocko [off-list ref] wrote:

quoted

On Mon 29-01-18 23:35:22, Florian Westphal wrote:

quoted

Kirill A. Shutemov [off-list ref] wrote:

[...]

quoted

quoted

I hate what I'm saying, but I guess we need some tunable here.
Not sure what exactly.

Would memcg help?

That really depends. I would have to check whether vmalloc path obeys
__GFP_ACCOUNT (I suspect it does except for page tables allocations but
that shouldn't be a big deal). But then the other potential problem is
the life time of the xt_table_info (or other potentially large) data
structures. Are they bound to any process life time.

No.

quoted

Because if they are
not then the OOM killer will not help. The OOM panic earlier in this
thread suggests it doesn't because the test case managed to eat all the
available memory and killed all the eligible tasks which didn't help.

Yes, which is why we do not want any OOM killer invocation in first
place...

The problem is that as soon as you eat that memory and ask for more
until you fail with ENOMEM then the OOM is simply unavoidable.
-- 
Michal Hocko
SUSE Labs