From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933131AbcASXBz (ORCPT ); Tue, 19 Jan 2016 18:01:55 -0500 Received: from mail-pf0-f170.google.com ([209.85.192.170]:35027 "EHLO mail-pf0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932414AbcASXBq (ORCPT ); Tue, 19 Jan 2016 18:01:46 -0500 Date: Tue, 19 Jan 2016 15:01:44 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: One Thousand Gnomes cc: Michal Hocko , linux-mm@kvack.org, Tetsuo Handa , LKML Subject: Re: [RFC 1/3] oom, sysrq: Skip over oom victims and killed tasks In-Reply-To: <20160115153721.7d363aef@lxorguk.ukuu.org.uk> Message-ID: References: <1452632425-20191-1-git-send-email-mhocko@kernel.org> <1452632425-20191-2-git-send-email-mhocko@kernel.org> <20160113093046.GA28942@dhcp22.suse.cz> <20160114110037.GC29943@dhcp22.suse.cz> <20160115101218.GB14112@dhcp22.suse.cz> <20160115153721.7d363aef@lxorguk.ukuu.org.uk> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 15 Jan 2016, One Thousand Gnomes wrote: > > > I think it's time to kill sysrq+F and I'll send those two patches > > > unless there is a usecase I'm not aware of. > > > > I have described one in the part you haven't quoted here. Let me repeat: > > : Your system might be trashing to the point you are not able to log in > > : and resolve the situation in a reasonable time yet you are still not > > : OOM. sysrq+f is your only choice then. > > > > Could you clarify why it is better to ditch a potentially usefull > > emergency tool rather than to make it work reliably and predictably? > > Even if it doesn't work reliably and predictably it is *still* better > than removing it as it works currently. Today we have "might save you a > reboot", the removal turns it into "you'll have to reboot". That's a > regression. > Under what circumstance are you supposing to use sysrq+f in your hypothetical? If you have access to the shell, then you can kill any process at random (and you may even be able to make better realtime decisions than the oom killer) and it will gain access to memory reserves immediately under my proposal when it tries to allocate memory. The net result is that calling the oom killer is no better than you issuing the SIGKILL yourself. This doesn't work if your are supposing to use sysrq+f without the ability to get access to the shell. That's the point, I believe, that Michal has raised in this thread. I'd like to address that issue directly rather than requiring human intervention to fix. If you have deployed a very large number of machines to your datacenters, you don't possibly have the resources to do this.