From: Sebastian Frias <sf84@laposte.net>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Michal Hocko <mhocko@kernel.org>, Mason <slash.tmp@free.fr>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: add config option to select the initial overcommit mode
Date: Mon, 23 May 2016 15:11:44 +0200 [thread overview]
Message-ID: <57430190.1080401@laposte.net> (raw)
In-Reply-To: <20160513164113.6317c491@lxorguk.ukuu.org.uk>
Hi Alan,
On 05/13/2016 05:41 PM, One Thousand Gnomes wrote:
>> My understanding is that there was a time when there was no overcommit at all.
>> If that's the case, understanding why overcommit was introduced would be helpful.
>
> Linux always had overcommit.
>
> The origin of overcommit is virtual memory for the most part. In a
> classic swapping system without VM the meaning of brk() and thus malloc()
> is that it allocates memory (or swap). Likewise this is true of fork()
> and stack extension.
>
> In a virtual memory system these allocate _address space_. It does not
> become populated except by page faulting, copy on write and the like. It
> turns out that for most use cases on a virtual memory system we get huge
> amounts of page sharing or untouched space.
>
> Historically Linux did guess based overcommit and I added no overcommit
> support way back when, along with 'anything is allowed' support for
> certain HPC use cases.
>
> The beancounter patches combined with this made the entire setup
> completely robust but the beancounters never hit upstream although years
> later they became part of the basis of the cgroups.
>
> You can sort of set a current Linux up for definitely no overcommit using
> cgroups and no overcommit settings. It works for most stuff although last
> I checked most graphics drivers were terminally broken (and not just to
> no overcommit but to the point you can remote DoS Linux boxes with a
> suitably constructed web page and chrome browser)
>
> Alan
>
Thanks for your comment, it certainly provides more clues and provided some history about the "overcommit" setting.
I will see if we can do what we want with cgroups.
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Frias <sf84@laposte.net>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Michal Hocko <mhocko@kernel.org>, Mason <slash.tmp@free.fr>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: add config option to select the initial overcommit mode
Date: Mon, 23 May 2016 15:11:44 +0200 [thread overview]
Message-ID: <57430190.1080401@laposte.net> (raw)
In-Reply-To: <20160513164113.6317c491@lxorguk.ukuu.org.uk>
Hi Alan,
On 05/13/2016 05:41 PM, One Thousand Gnomes wrote:
>> My understanding is that there was a time when there was no overcommit at all.
>> If that's the case, understanding why overcommit was introduced would be helpful.
>
> Linux always had overcommit.
>
> The origin of overcommit is virtual memory for the most part. In a
> classic swapping system without VM the meaning of brk() and thus malloc()
> is that it allocates memory (or swap). Likewise this is true of fork()
> and stack extension.
>
> In a virtual memory system these allocate _address space_. It does not
> become populated except by page faulting, copy on write and the like. It
> turns out that for most use cases on a virtual memory system we get huge
> amounts of page sharing or untouched space.
>
> Historically Linux did guess based overcommit and I added no overcommit
> support way back when, along with 'anything is allowed' support for
> certain HPC use cases.
>
> The beancounter patches combined with this made the entire setup
> completely robust but the beancounters never hit upstream although years
> later they became part of the basis of the cgroups.
>
> You can sort of set a current Linux up for definitely no overcommit using
> cgroups and no overcommit settings. It works for most stuff although last
> I checked most graphics drivers were terminally broken (and not just to
> no overcommit but to the point you can remote DoS Linux boxes with a
> suitably constructed web page and chrome browser)
>
> Alan
>
Thanks for your comment, it certainly provides more clues and provided some history about the "overcommit" setting.
I will see if we can do what we want with cgroups.
Best regards,
Sebastian
next prev parent reply other threads:[~2016-05-23 13:11 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-10 11:56 [PATCH] mm: add config option to select the initial overcommit mode Sebastian Frias
2016-05-10 11:56 ` Sebastian Frias
2016-05-10 12:00 ` Fwd: " Sebastian Frias
2016-05-10 12:39 ` Andy Whitcroft
2016-05-10 13:02 ` Sebastian Frias
2016-05-13 8:04 ` Michal Hocko
2016-05-13 8:04 ` Michal Hocko
2016-05-13 8:44 ` Mason
2016-05-13 8:44 ` Mason
2016-05-13 9:52 ` Michal Hocko
2016-05-13 9:52 ` Michal Hocko
2016-05-13 10:18 ` Mason
2016-05-13 10:18 ` Mason
2016-05-13 10:42 ` Sebastian Frias
2016-05-13 10:42 ` Sebastian Frias
2016-05-13 11:44 ` Michal Hocko
2016-05-13 11:44 ` Michal Hocko
2016-05-13 12:15 ` Mason
2016-05-13 12:15 ` Mason
2016-05-13 14:01 ` Michal Hocko
2016-05-13 14:01 ` Michal Hocko
2016-05-13 14:15 ` Sebastian Frias
2016-05-13 14:15 ` Sebastian Frias
2016-05-13 15:04 ` One Thousand Gnomes
2016-05-13 15:04 ` One Thousand Gnomes
2016-05-13 15:37 ` Sebastian Frias
2016-05-13 15:37 ` Sebastian Frias
2016-05-13 15:43 ` One Thousand Gnomes
2016-05-13 15:43 ` One Thousand Gnomes
2016-05-17 8:24 ` Sebastian Frias
2016-05-17 8:24 ` Sebastian Frias
2016-05-17 8:57 ` Michal Hocko
2016-05-17 8:57 ` Michal Hocko
2016-05-17 16:16 ` Sebastian Frias
2016-05-17 16:16 ` Sebastian Frias
2016-05-17 17:29 ` Austin S. Hemmelgarn
2016-05-17 17:29 ` Austin S. Hemmelgarn
2016-05-18 15:19 ` Sebastian Frias
2016-05-18 15:19 ` Sebastian Frias
2016-05-18 16:28 ` Austin S. Hemmelgarn
2016-05-18 16:28 ` Austin S. Hemmelgarn
2016-05-17 20:16 ` Michal Hocko
2016-05-17 20:16 ` Michal Hocko
2016-05-18 15:18 ` Sebastian Frias
2016-05-18 15:18 ` Sebastian Frias
2016-05-19 7:14 ` Michal Hocko
2016-05-19 7:14 ` Michal Hocko
2016-05-13 17:01 ` Austin S. Hemmelgarn
2016-05-13 17:01 ` Austin S. Hemmelgarn
2016-05-13 13:27 ` Austin S. Hemmelgarn
2016-05-13 13:27 ` Austin S. Hemmelgarn
2016-05-13 9:52 ` Sebastian Frias
2016-05-13 9:52 ` Sebastian Frias
2016-05-13 12:00 ` Michal Hocko
2016-05-13 12:00 ` Michal Hocko
2016-05-13 12:39 ` Sebastian Frias
2016-05-13 12:39 ` Sebastian Frias
2016-05-13 13:11 ` Austin S. Hemmelgarn
2016-05-13 13:11 ` Austin S. Hemmelgarn
2016-05-13 13:32 ` Sebastian Frias
2016-05-13 13:32 ` Sebastian Frias
2016-05-13 13:51 ` Austin S. Hemmelgarn
2016-05-13 13:51 ` Austin S. Hemmelgarn
2016-05-13 14:35 ` Sebastian Frias
2016-05-13 14:35 ` Sebastian Frias
2016-05-13 14:54 ` Michal Hocko
2016-05-13 14:54 ` Michal Hocko
2016-05-13 15:15 ` Austin S. Hemmelgarn
2016-05-13 15:15 ` Austin S. Hemmelgarn
2016-05-13 13:34 ` Sebastian Frias
2016-05-13 13:34 ` Sebastian Frias
2016-05-13 14:14 ` Austin S. Hemmelgarn
2016-05-13 14:14 ` Austin S. Hemmelgarn
2016-05-13 14:23 ` Sebastian Frias
2016-05-13 14:23 ` Sebastian Frias
2016-05-13 15:02 ` Austin S. Hemmelgarn
2016-05-13 15:02 ` Austin S. Hemmelgarn
2016-05-13 15:01 ` One Thousand Gnomes
2016-05-13 15:01 ` One Thousand Gnomes
2016-05-13 15:15 ` Sebastian Frias
2016-05-13 15:15 ` Sebastian Frias
2016-05-13 15:25 ` Michal Hocko
2016-05-13 15:25 ` Michal Hocko
2016-05-13 14:51 ` Michal Hocko
2016-05-13 14:51 ` Michal Hocko
2016-05-13 14:59 ` Mason
2016-05-13 14:59 ` Mason
2016-05-13 15:11 ` One Thousand Gnomes
2016-05-13 15:11 ` One Thousand Gnomes
2016-05-13 15:26 ` Michal Hocko
2016-05-13 15:26 ` Michal Hocko
2016-05-13 15:32 ` Sebastian Frias
2016-05-13 15:32 ` Sebastian Frias
2016-05-13 15:10 ` Sebastian Frias
2016-05-13 15:10 ` Sebastian Frias
2016-05-13 15:41 ` One Thousand Gnomes
2016-05-13 15:41 ` One Thousand Gnomes
2016-05-23 13:11 ` Sebastian Frias [this message]
2016-05-23 13:11 ` Sebastian Frias
2016-05-17 9:03 ` Mason
2016-05-17 9:03 ` Mason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57430190.1080401@laposte.net \
--to=sf84@laposte.net \
--cc=akpm@linux-foundation.org \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=slash.tmp@free.fr \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.