Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932722Ab0BPHxp (ORCPT ); Tue, 16 Feb 2010 02:53:45 -0500 Received: from smtp-out.google.com ([216.239.33.17]:51107 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932686Ab0BPHxk (ORCPT ); Tue, 16 Feb 2010 02:53:40 -0500 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:user-agent:mime-version:content-type:x-system-of-record; b=jBfkvNTzaNdGsIlZkFLrvLPk+jS7YWGUPASsI0MqS8HxZiDP1GnV2ZOQggITcI7G1 Gf6cuiV3Hn7L4/4pzuvqg== Date: Mon, 15 Feb 2010 23:53:33 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Nick Piggin cc: Andrew Morton , Rik van Riel , KAMEZAWA Hiroyuki , Andrea Arcangeli , Balbir Singh , Lubos Lunak , KOSAKI Motohiro , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [patch -mm 4/9 v2] oom: remove compulsory panic_on_oom mode In-Reply-To: <20100216072047.GH5723@laptop> Message-ID: References: <20100216062035.GA5723@laptop> <20100216072047.GH5723@laptop> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2221 Lines: 50 On Tue, 16 Feb 2010, Nick Piggin wrote: > > Because it is inconsistent at the user's expense, it has never panicked > > the machine for memory controller ooms, so why is a cpuset or mempolicy > > constrained oom conditions any different? > > Well memory controller was added later, wasn't it? So if you think > that's a bug then a fix to panic on memory controller ooms might > be in order. > But what about the existing memcg users who set panic_on_oom == 2 and don't expect the memory controller to be influenced by that? > > It also panics the machine even > > on VM_FAULT_OOM which is ridiculous, > > Why? > Because the oom killer was never called for VM_FAULT_OOM before, we simply sent a SIGKILL to current, i.e. the original panic_on_oom semantics were not even enforced. > > the tunable is certainly not being > > used how it was documented > > Why not? The documentation seems to match the implementation. > It was meant to panic the machine anytime it was out of memory, regardless of the constraint, but that obviously doesn't match the memory controller case. Just because cpusets and mempolicies decide to use the oom killer as a mechanism for enforcing a user-defined policy does not mean that we want to panic for them: mempolicies, for example, are user created and do not require any special capability. Does it seem reasonable that an oom condition on those mempolicy nodes should panic the machine when killing the offender is possible (and perhaps even encouraged if the user sets a high /proc/pid/oom_score_adj?) In other words, is an admin setting panic_on_oom == 2 really expecting that no application will use set_mempolicy() or do an mbind()? This is a very error-prone interface that needs to be dealt with on a case-by-case basis and the perfect way to do that is by setting the affected tasks to be OOM_DISABLE; that interface, unlike panic_on_oom == 2, is very well understood by those with CAP_SYS_RESOURCE. -- 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/