From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f71.google.com (mail-wm0-f71.google.com [74.125.82.71]) by kanga.kvack.org (Postfix) with ESMTP id D96926B0260 for ; Fri, 13 May 2016 11:37:23 -0400 (EDT) Received: by mail-wm0-f71.google.com with SMTP id w143so11882987wmw.3 for ; Fri, 13 May 2016 08:37:23 -0700 (PDT) Received: from smtp.laposte.net (smtpoutz299.laposte.net. [178.22.154.199]) by mx.google.com with ESMTPS id k203si4188120wmd.110.2016.05.13.08.37.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 May 2016 08:37:22 -0700 (PDT) Received: from smtp.laposte.net (localhost [127.0.0.1]) by lpn-prd-vrout011 (Postfix) with ESMTP id 6398852A7B3 for ; Fri, 13 May 2016 17:37:22 +0200 (CEST) Received: from lpn-prd-vrin004 (lpn-prd-vrin004.prosodie [10.128.63.5]) by lpn-prd-vrout011 (Postfix) with ESMTP id 6234152A742 for ; Fri, 13 May 2016 17:37:22 +0200 (CEST) Received: from lpn-prd-vrin004 (localhost [127.0.0.1]) by lpn-prd-vrin004 (Postfix) with ESMTP id 4C0C770FF90 for ; Fri, 13 May 2016 17:37:22 +0200 (CEST) Message-ID: <5735F4B1.1010704@laposte.net> Date: Fri, 13 May 2016 17:37:21 +0200 From: Sebastian Frias MIME-Version: 1.0 Subject: Re: [PATCH] mm: add config option to select the initial overcommit mode References: <5731CC6E.3080807@laposte.net> <20160513080458.GF20141@dhcp22.suse.cz> <573593EE.6010502@free.fr> <20160513095230.GI20141@dhcp22.suse.cz> <5735AA0E.5060605@free.fr> <20160513114429.GJ20141@dhcp22.suse.cz> <5735C567.6030202@free.fr> <20160513140128.GQ20141@dhcp22.suse.cz> <20160513160410.10c6cea6@lxorguk.ukuu.org.uk> In-Reply-To: <20160513160410.10c6cea6@lxorguk.ukuu.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: One Thousand Gnomes , Michal Hocko Cc: Mason , linux-mm@kvack.org, Andrew Morton , Linus Torvalds , LKML Hi Alan, On 05/13/2016 05:04 PM, One Thousand Gnomes wrote: >>> Perhaps Sebastian's choice could be made to depend on CONFIG_EMBEDDED, >>> rather than CONFIG_EXPERT? >> >> Even if the overcommit behavior is different on those systems the >> primary question hasn't been answered yet. Why cannot this be done from >> the userspace? In other words what wouldn't work properly? > > Most allocations in C have no mechanism to report failure. > > Stakc expansion failure is not reportable. Copy on write failure is not > reportable and so on. But wouldn't those affect a given process at at time? Does that means that the OOM-killer is woken up to kill process X when those situations arise on process Y? Also, under what conditions would copy-on-write fail? Best regards, Sebastian -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753505AbcEMPh1 (ORCPT ); Fri, 13 May 2016 11:37:27 -0400 Received: from smtpoutz299.laposte.net ([178.22.154.199]:60033 "EHLO smtp.laposte.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751917AbcEMPhY (ORCPT ); Fri, 13 May 2016 11:37:24 -0400 Message-ID: <5735F4B1.1010704@laposte.net> Date: Fri, 13 May 2016 17:37:21 +0200 From: Sebastian Frias User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: One Thousand Gnomes , Michal Hocko CC: Mason , linux-mm@kvack.org, Andrew Morton , Linus Torvalds , LKML Subject: Re: [PATCH] mm: add config option to select the initial overcommit mode References: <5731CC6E.3080807@laposte.net> <20160513080458.GF20141@dhcp22.suse.cz> <573593EE.6010502@free.fr> <20160513095230.GI20141@dhcp22.suse.cz> <5735AA0E.5060605@free.fr> <20160513114429.GJ20141@dhcp22.suse.cz> <5735C567.6030202@free.fr> <20160513140128.GQ20141@dhcp22.suse.cz> <20160513160410.10c6cea6@lxorguk.ukuu.org.uk> In-Reply-To: <20160513160410.10c6cea6@lxorguk.ukuu.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-VR-SrcIP: 83.142.147.193 X-VR-FullState: 0 X-VR-Score: -100 X-VR-Cause-1: gggruggvucftvghtrhhoucdtuddrfeekledrvddugdeklecutefuodetggdotefrodftvfcurfhrohhf X-VR-Cause-2: ihhlvgemucfntefrqffuvffgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhs X-VR-Cause-3: ucdlqddutddtmdenucfjughrpefkfffhfgggvffufhgjtgfgsehtjegrtddtfeehnecuhfhrohhmpefu X-VR-Cause-4: vggsrghsthhirghnucfhrhhirghsuceoshhfkeegsehlrghpohhsthgvrdhnvghtqeenucfkphepkeef X-VR-Cause-5: rddugedvrddugeejrdduleefnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhhtpdhhvghloheplgdu X-VR-Cause-6: jedvrddvjedrtddrvddugegnpdhinhgvthepkeefrddugedvrddugeejrdduleefpdhmrghilhhfrhho X-VR-Cause-7: mhepshhfkeegsehlrghpohhsthgvrdhnvghtpdhrtghpthhtohepghhnohhmvghssehlgihorhhguhhk X-VR-Cause-8: rdhukhhuuhdrohhrghdruhhk X-VR-AvState: No X-VR-State: 0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Alan, On 05/13/2016 05:04 PM, One Thousand Gnomes wrote: >>> Perhaps Sebastian's choice could be made to depend on CONFIG_EMBEDDED, >>> rather than CONFIG_EXPERT? >> >> Even if the overcommit behavior is different on those systems the >> primary question hasn't been answered yet. Why cannot this be done from >> the userspace? In other words what wouldn't work properly? > > Most allocations in C have no mechanism to report failure. > > Stakc expansion failure is not reportable. Copy on write failure is not > reportable and so on. But wouldn't those affect a given process at at time? Does that means that the OOM-killer is woken up to kill process X when those situations arise on process Y? Also, under what conditions would copy-on-write fail? Best regards, Sebastian