From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932948AbbHYOZK (ORCPT ); Tue, 25 Aug 2015 10:25:10 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:37729 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754541AbbHYOZH (ORCPT ); Tue, 25 Aug 2015 10:25:07 -0400 Date: Tue, 25 Aug 2015 16:25:04 +0200 From: Michal Hocko To: David Rientjes Cc: Andrew Morton , Mel Gorman , Johannes Weiner , Oleg Nesterov , Vlastimil Babka , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Tetsuo Handa Subject: Re: [patch -mm] mm, oom: add global access to memory reserves on livelock Message-ID: <20150825142503.GE6285@dhcp22.suse.cz> References: <20150821081745.GG23723@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 24-08-15 14:04:28, David Rientjes wrote: > On Fri, 21 Aug 2015, Michal Hocko wrote: > > > There might be many threads waiting for the allocation and this can lead > > to quick oom reserves depletion without releasing resources which are > > holding back the oom victim. As Tetsuo has shown, such a load can be > > generated from the userspace without root privileges so it is much > > easier to make the system _completely_ unusable with this patch. Not that > > having an OOM deadlock would be great but you still have emergency tools > > like sysrq triggered OOM killer to attempt to sort the situation out. > > Once your are out of reserves nothing will help you, though. So I think it > > is a bad idea to give access to reserves without any throttling. > > > > I don't believe a solution that requires admin intervention is > maintainable. Why? > It would be better to reboot when memory reserves are fully depleted. The question is when are the reserves depleted without any way to replenish them. While playing with GFP_NOFS patch set which gives __GFP_NOFAIL allocations access to memory reserves (http://marc.info/?l=linux-mm&m=143876830916540&w=2) I could see the warning hit while the system still resurrected from the memory pressure. > > Johannes' idea to give a partial access to memory reserves to the task > > which has invoked the OOM killer was much better IMO. > > That's what this patch does, just without the "partial." Processes are > required to reclaim and then invoke the oom killler every time an > allocation is made using memory reserves with this approach after the > expiration has lapsed. > > We can discuss only allowing partial access to memory reserves equal to > ALLOC_HARD | ALLOC_HARDER, or defining a new watermark, but I'm concerned > about what happens when that threshold is reached and the oom killer is > still livelocked. It would seem better to attempt recovery at whatever > cost and then panic if fully depleted. I think an OOM reserve/watermark makes more sense. It will not solve the livelock but neithere granting the full access to reserves will. But the partial access has a potential to leave some others means to intervene. -- Michal Hocko SUSE Labs