Date: Fri, 18 Dec 2015 13:11:13 +0100
From: Michal Hocko <mhocko@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>,
        Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
        David Rientjes <rientjes@google.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Oleg Nesterov <oleg@redhat.com>, Hugh Dickins <hughd@google.com>,
        Andrea Argangeli <andrea@kernel.org>, Rik van Riel <riel@redhat.com>,
        linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] mm, oom: introduce oom reaper
Message-ID: <20151218121112.GF28443@dhcp22.suse.cz>
References: <1450204575-13052-1-git-send-email-mhocko@kernel.org>
 <20151216165035.38a4d9b84600d6348a3cf4bf@linux-foundation.org>
 <20151217130223.GE18625@dhcp22.suse.cz>
 <20151217131356.83d920b7c250a785aa132139@linux-foundation.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151217131356.83d920b7c250a785aa132139@linux-foundation.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1707
Lines: 42

On Thu 17-12-15 13:13:56, Andrew Morton wrote:
[...]
> Also, re-reading your description:
> 
> : It has been shown (e.g.  by Tetsuo Handa) that it is not that hard to
> : construct workloads which break the core assumption mentioned above and
> : the OOM victim might take unbounded amount of time to exit because it
> : might be blocked in the uninterruptible state waiting for on an event
> : (e.g.  lock) which is blocked by another task looping in the page
> : allocator.
> 
> So the allocating task has done an oom-kill and is waiting for memory
> to become available.  The killed task is stuck on some lock, unable to
> free memory.
> 
> But the problematic lock will sometimes be the killed tasks's mmap_sem,
> so the reaper won't reap anything.  This scenario requires that the
> mmap_sem is held for writing, which sounds like it will be uncommon. 

Yes, I have mentioned that in the changelog:
"
oom_reaper has to take mmap_sem on the target task for reading so the
solution is not 100% because the semaphore might be held or blocked for
write but the probability is reduced considerably wrt. basically any
lock blocking forward progress as described above.
"

Another thing is to do is to change down_write(mmap_sem) to
down_write_killable in most cases where we have a clear ENITR semantic.
This is on my todo list.

> hm.  sigh.  I hate the oom-killer.  Just buy some more memory already!

Tell me something about that...
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/