Re: [PATCH] mm/page_alloc: Wait for oom_lock before retrying.

[Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>]

Michal Hocko wrote:
> On Mon 12-12-16 21:12:06, Tetsuo Handa wrote:
> > > I would rather not mix the two. Even if both use show_mem then there is
> > > no reason to abuse the oom_lock.
> > > 
> > > Maybe I've missed that but you haven't responded to the question whether
> > > the warn_lock actually resolves the problem you are seeing.
> > 
> > I haven't tried warn_lock, but is warn_lock in warn_alloc() better than
> > serializing oom_lock in __alloc_pages_may_oom() ? I think we don't need to
> > waste CPU cycles before the OOM killer sends SIGKILL.
> 
> Yes, I find a separate lock better because there is no real reason to
> abuse an unrelated lock.

Using separate lock for warn_alloc() is fine for me. I can still consider
serialization of oom_lock independent with warn_alloc(). But

> > Maybe more, but no need to enumerate in this thread.
> > How many of these precautions can be achieved by tuning warn_alloc() ?
> > printk() tries to solve unbounded delay problem by using (I guess) a
> > dedicated kernel thread. I don't think we can achieve these precautions
> > without a centralized state tracking which can sleep and synchronize as
> > needed.
> > 
> > Quite few people are responding to discussions regarding almost
> > OOM situation. I beg for your joining to discussions.
> 
> I have already stated my position. I do not think that the code this
> patch introduces is really justified for the advantages it provides over
> a simple warn_alloc approach. Additional debugging information might be
> nice but not necessary in 99% cases. If there are definciences in
> warn_alloc (which I agree there are if there are thousands of contexts
> hitting the path) then let's try to address them.

I'm not happy with keeping kmallocwd out-of-tree.

http://I-love.SAKURA.ne.jp/tmp/serial-20161212.txt.xz is a console log
which I've just captured using stock 4.9 kernel (as a preparation step for
trying http://lkml.kernel.org/r/20161212131910.GC3185@dhcp22.suse.cz ) using
http://lkml.kernel.org/r/201612080029.IBD55588.OSOFOtHVMLQFFJ@I-love.SAKURA.ne.jp .
Only warn_alloc() by GFP_NOIO allocation request was reported (uptime > 148).
Guessing from

  INFO: task kswapd0:60 blocked for more than 60 seconds.

message, I hit kswapd v.s. shrink_inactive_list() trap. But there are
no other hints which would have been reported if kmallocwd is available.
This is one of unsolvable definciences in warn_alloc() (or any synchronous
watchdog).

It is administrators who decide whether to utilize debugging capability
with state tracking. Let's give administrators a choice and a chance.

Although you think most users won't need kmallcwd, there is no objection
for asynchronous watchdog, isn't it?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>