From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752752AbcEMJwj (ORCPT ); Fri, 13 May 2016 05:52:39 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:34156 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751739AbcEMJwh (ORCPT ); Fri, 13 May 2016 05:52:37 -0400 Date: Fri, 13 May 2016 11:52:30 +0200 From: Michal Hocko To: Mason Cc: Sebastian Frias , linux-mm@kvack.org, Andrew Morton , Linus Torvalds , LKML Subject: Re: [PATCH] mm: add config option to select the initial overcommit mode Message-ID: <20160513095230.GI20141@dhcp22.suse.cz> References: <5731CC6E.3080807@laposte.net> <20160513080458.GF20141@dhcp22.suse.cz> <573593EE.6010502@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573593EE.6010502@free.fr> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. -- Michal Hocko SUSE Labs