Re: [PATCH] mm,page_alloc: Serialize warn_alloc() if schedulable.

From: Michal Hocko <mhocko@suse.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	xiyou.wangcong@gmail.com, dave.hansen@intel.com,
	hannes@cmpxchg.org, mgorman@suse.de, vbabka@suse.cz,
	sergey.senozhatsky.work@gmail.com, pmladek@suse.com
Subject: Re: [PATCH] mm,page_alloc: Serialize warn_alloc() if schedulable.
Date: Fri, 14 Jul 2017 14:48:33 +0200	[thread overview]
Message-ID: <20170714124833.GO2618@dhcp22.suse.cz> (raw)
In-Reply-To: <201707142130.JJF10142.FHJFOQSOOtMVLF@I-love.SAKURA.ne.jp>

On Fri 14-07-17 21:30:54, Tetsuo Handa wrote:
> Michal Hocko wrote:
[...]
> > As I've said earlier, if there is no other way to make printk work without all
> > these nasty side effected then I would be OK to add a printk context
> > specific calls into the oom killer.
> > 
> > Removing the rest because this is again getting largely tangent. The
> > primary problem you are seeing is that we stumble over printk here.
> > Unless I can see a sound argument this is not the case it doesn't make
> > any sense to discuss allocator changes.
> 
> You are still ignoring my point. I agree that we stumble over printk(), but
> printk() is nothing but one of locations we stumble.

I am not ignoring it. You just mix too many things together to have a
meaningful conversation...

> Look at schedule_timeout_killable(1) in out_of_memory() which is called with
> oom_lock still held. I'm reporting that even printk() is offloaded to printk
> kernel thread, scheduling priority can make schedule_timeout_killable(1) sleep
> for more than 12 minutes (which is intended to sleep for only one millisecond).
> (I gave up waiting and pressed SysRq-i. I can't imagine how long it would have
> continued sleeping inside schedule_timeout_killable(1) with oom_lock held.)
> 
> Without cooperation from other allocating threads which failed to hold oom_lock,
> it is dangerous to keep out_of_memory() preemptible/schedulable context.

I have already tried to explain that this is something that the whole
reclaim path suffers from the priority inversions problem because it has
never been designed to handle that. You are just poking to one
particular path of the reclaim stack and missing the whole forest for a
tree. How the hack is this any different from a reclaim path stumbling
over a lock down inside the filesystem and stalling basically everybody
from making a reasonable progress? Is this a problem? Of course it is,
theoretically. In practice not all that much to go and reimplement the
whole stack. At least I haven't seen any real life reports complaining
about this.
-- 
Michal Hocko
SUSE Labs

--
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>