lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 13 May 2016 16:15:13 +0200
From:	Sebastian Frias <sf84@...oste.net>
To:	Michal Hocko <mhocko@...nel.org>, Mason <slash.tmp@...e.fr>
CC:	linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: add config option to select the initial overcommit
 mode

Hi Michal,

On 05/13/2016 04:01 PM, Michal Hocko wrote:
> On Fri 13-05-16 14:15:35, Mason wrote:
>> On 13/05/2016 13:44, Michal Hocko wrote:
>>
>>> Anyway, this is my laptop where I do not run anything really special
>>> (xfce, browser, few consoles, git, mutt):
>>> $ grep Commit /proc/meminfo
>>> CommitLimit:     3497288 kB
>>> Committed_AS:    3560804 kB
>>>
>>> I am running with the default overcommit setup so I do not care about
>>> the limit but the Committed_AS will tell you how much is actually
>>> committed. I am definitelly not out of memory:
>>> $ free
>>>               total        used        free      shared  buff/cache   available
>>> Mem:        3922584     1724120      217336      105264     1981128     2036164
>>> Swap:       1535996      386364     1149632
>>
>> I see. Thanks for the data point.
>>
>> I had a different type of system in mind.
>> 256 to 512 MB of RAM, no swap.
>> 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?
> 

You are right, and I said that since the beginning, nothing prevents the userspace from doing it.

But it'd be interesting to know the history of this option, for example, why it is left for userspace.
Are there systems that dynamically change this setting?

Best regards,

Sebastian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ