On Tue 30-01-18 09:11:27, Florian Westphal wrote: > Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > On Mon 29-01-18 23:35:22, Florian Westphal wrote: > > > Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> wrote: > > [...] > > > > 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. > > > 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
