From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752172AbcEMKTP (ORCPT ); Fri, 13 May 2016 06:19:15 -0400 Received: from smtp2-g21.free.fr ([212.27.42.2]:61899 "EHLO smtp2-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751442AbcEMKTO (ORCPT ); Fri, 13 May 2016 06:19:14 -0400 Subject: Re: [PATCH] mm: add config option to select the initial overcommit mode To: Michal Hocko Cc: Sebastian Frias , linux-mm@kvack.org, Andrew Morton , Linus Torvalds , LKML References: <5731CC6E.3080807@laposte.net> <20160513080458.GF20141@dhcp22.suse.cz> <573593EE.6010502@free.fr> <20160513095230.GI20141@dhcp22.suse.cz> From: Mason Message-ID: <5735AA0E.5060605@free.fr> Date: Fri, 13 May 2016 12:18:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39 MIME-Version: 1.0 In-Reply-To: <20160513095230.GI20141@dhcp22.suse.cz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/05/2016 11:52, Michal Hocko wrote: > On Fri 13-05-16 10:44:30, Mason wrote: >> On 13/05/2016 10:04, Michal Hocko wrote: >> >>> On Tue 10-05-16 13:56:30, Sebastian Frias wrote: >>> [...] >>>> NOTE: I understand that the overcommit mode can be changed dynamically thru >>>> sysctl, but on embedded systems, where we know in advance that overcommit >>>> will be disabled, there's no reason to postpone such setting. >>> >>> To be honest I am not particularly happy about yet another config >>> option. At least not without a strong reason (the one above doesn't >>> sound that way). The config space is really large already. >>> So why a later initialization matters at all? Early userspace shouldn't >>> consume too much address space to blow up later, no? >> >> One thing I'm not quite clear on is: why was the default set >> to over-commit on? > > Because many applications simply rely on large and sparsely used address > space, I guess. What kind of applications are we talking about here? Server apps? Client apps? Supercomputer apps? I heard some HPC software use large sparse matrices, but is it a common idiom to request large allocations, only to use a fraction of it? If you'll excuse the slight trolling, I'm sure many applications don't expect being randomly zapped by the OOM killer ;-) > That's why the default is GUESS where we ignore the cumulative > charges and simply check the current state and blow up only when > the current request is way too large. I wouldn't call denying a request "blowing up". Application will receive NULL, and is supposed to handle it gracefully. "Blowing up" is receiving SIGKILL because another process happened to allocate too much memory. Regards.