From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: mtk.manpages@gmail.com, Manfred Spraul <manfred@colorfullife.com>,
Davidlohr Bueso <davidlohr.bueso@hp.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Greg Thelen <gthelen@google.com>,
aswin@hp.com, "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL
Date: Tue, 23 Sep 2014 07:24:23 +0200 [thread overview]
Message-ID: <54210407.1000602@gmail.com> (raw)
In-Reply-To: <1401823560.4911.2.camel@buesod1.americas.hpqcorp.net>
On 06/03/2014 09:26 PM, Davidlohr Bueso wrote:
> On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote:
>> Hi Manfred,
>>
>> On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul
>> <manfred@colorfullife.com> wrote:
>>> Hi all,
>>>
>>> the increase of SHMMAX/SHMALL is now a 4 patch series.
>>> I don't have ideas how to improve it further.
>>
>> On the assumption that your patches are heading to mainline, could you
>> send me a man-pages patch for the changes?
>
> It seems we're still behind here and the 3.16 merge window is already
> opened. Please consider this, and again feel free to add/modify as
> necessary. I think adding a note as below is enough and was hesitant to
> add a lot of details... Thanks.
>
> 8<--------------------------------------------------
> From: Davidlohr Bueso <davidlohr@hp.com>
> Subject: [PATCH] shmget.2: document new limits for shmmax/shmall
>
> These limits have been recently enlarged and
> modifying them is no longer really necessary.
> Update the manpage.
>
> Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
> ---
> man2/shmget.2 | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/man2/shmget.2 b/man2/shmget.2
> index f781048..77764ea 100644
> --- a/man2/shmget.2
> +++ b/man2/shmget.2
> @@ -299,6 +299,11 @@ with 8kB page size, it yields 2^20 (1048576).
>
> On Linux, this limit can be read and modified via
> .IR /proc/sys/kernel/shmall .
> +As of Linux 3.16, the default value for this limit is increased to
> +.B ULONG_MAX - 2^24
> +pages, which is as large as it can be without helping userspace overflow
> +the values. Modifying this limit is therefore discouraged. This is suitable
> +for both 32 and 64-bit systems.
> .TP
> .B SHMMAX
> Maximum size in bytes for a shared memory segment.
> @@ -306,6 +311,12 @@ Since Linux 2.2, the default value of this limit is 0x2000000 (32MB).
>
> On Linux, this limit can be read and modified via
> .IR /proc/sys/kernel/shmmax .
> +As of Linux 3.16, the default value for this limit is increased from 32Mb
> +to
> +.B ULONG_MAX - 2^24
> +bytes, which is as large as it can be without helping userspace overflow
> +the values. Modifying this limit is therefore discouraged. This is suitable
> +for both 32 and 64-bit systems.
> .TP
> .B SHMMIN
> Minimum size in bytes for a shared memory segment: implementation
David,
I applied various pieces from your patch on top of material
that I already had, so that now we have the text below describing
these limits. Comments/suggestions/improvements from all welcome.
Cheers,
Michael
SHMALL System-wide limit on the number of pages of shared memory.
On Linux, this limit can be read and modified via
/proc/sys/kernel/shmall. Since Linux 3.16, the default
value for this limit is:
ULONG_MAX - 2^24
The effect of this value (which is suitable for both
32-bit and 64-bit systems) is to impose no limitation on
allocations. This value, rather than ULONG_MAX, was cho‐
sen as the default to prevent some cases where historical
applications simply raised the existing limit without
first checking its current value. Such applications would
cause the value to overflow if the limit was set at
ULONG_MAX.
From Linux 2.4 up to Linux 3.15, the default value for
this limit was:
SHMMAX / PAGE_SIZE * (SHMMNI / 16)
If SHMMAX and SHMMNI were not modified, then multiplying
the result of this formula by the page size (to get a
value in bytes) yielded a value of 8 GB as the limit on
the total memory used by all shared memory segments.
SHMMAX Maximum size in bytes for a shared memory segment.
On Linux, this limit can be read and modified via
/proc/sys/kernel/shmmax. Since Linux 3.16, the default
value for this limit is:
ULONG_MAX - 2^24
The effect of this value (which is suitable for both
32-bit and 64-bit systems) is to impose no limitation on
allocations. See the description of SHMALL for a discus‐
sion of why this default value (rather than ULONG_MAX) is
used.
From Linux 2.2 up to Linux 3.15, the default value of this
limit was 0x2000000 (32MB).
Because it is not possible to map just part of a shared
memory segment, the amount of virtual memory places
another limit on the maximum size of a usable segment: for
example, on i386 the largest segments that can be mapped
have a size of around 2.8 GB, and on x86_64 the limit is
around 127 TB.
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
next prev parent reply other threads:[~2014-09-23 5:24 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-21 14:26 [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL Manfred Spraul
2014-04-21 14:26 ` [PATCH 1/4] ipc/shm.c: check for ulong overflows in shmat Manfred Spraul
2014-04-21 14:26 ` [PATCH 2/4] ipc/shm.c: check for overflows of shm_tot Manfred Spraul
2014-04-21 14:26 ` [PATCH 3/4] ipc/shm.c: check for integer overflow during shmget Manfred Spraul
2014-04-21 14:26 ` [PATCH 4/4] ipc/shm.c: Increase the defaults for SHMALL, SHMMAX Manfred Spraul
2014-04-22 18:21 ` Davidlohr Bueso
2014-04-22 18:28 ` Davidlohr Bueso
2014-04-22 20:17 ` Motohiro Kosaki
2014-04-23 5:01 ` Michael Kerrisk (man-pages)
2014-04-22 18:19 ` [PATCH 3/4] ipc/shm.c: check for integer overflow during shmget Davidlohr Bueso
2014-04-22 20:16 ` Motohiro Kosaki
2014-04-23 4:59 ` Michael Kerrisk (man-pages)
2014-04-22 18:18 ` [PATCH 2/4] ipc/shm.c: check for overflows of shm_tot Davidlohr Bueso
2014-04-22 20:16 ` Motohiro Kosaki
2014-04-23 4:58 ` Michael Kerrisk (man-pages)
2014-04-22 18:18 ` [PATCH 1/4] ipc/shm.c: check for ulong overflows in shmat Davidlohr Bueso
2014-04-22 20:15 ` Motohiro Kosaki
2014-04-23 4:58 ` Michael Kerrisk (man-pages)
2014-04-21 17:25 ` [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL Davidlohr Bueso
2014-04-22 4:23 ` Manfred Spraul
2014-04-22 18:18 ` Davidlohr Bueso
2014-04-23 2:53 ` [PATCH 5/4] ipc,shm: minor cleanups Davidlohr Bueso
2014-04-23 5:07 ` Michael Kerrisk (man-pages)
2014-04-23 5:25 ` Davidlohr Bueso
2014-04-23 5:28 ` Michael Kerrisk (man-pages)
2014-04-23 22:27 ` Andrew Morton
2014-04-23 22:35 ` Stephen Rothwell
2014-04-24 5:18 ` Michael Kerrisk (man-pages)
2014-04-24 17:21 ` Davidlohr Bueso
2014-04-23 18:18 ` Manfred Spraul
2014-05-02 13:16 ` [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL Michael Kerrisk (man-pages)
2014-05-06 20:06 ` Davidlohr Bueso
2014-05-06 20:40 ` Michael Kerrisk (man-pages)
2014-05-06 22:08 ` Davidlohr Bueso
2014-05-07 5:27 ` Michael Kerrisk (man-pages)
2014-05-07 18:22 ` Davidlohr Bueso
2014-05-07 19:17 ` [PATCH v2] ipc,shm: document new limits in the uapi header Davidlohr Bueso
2014-05-09 8:44 ` Michael Kerrisk (man-pages)
2014-05-11 20:46 ` Davidlohr Bueso
2014-05-12 7:44 ` Michael Kerrisk (man-pages)
2014-05-13 1:35 ` Davidlohr Bueso
2014-05-13 6:06 ` Michael Kerrisk (man-pages)
2014-05-06 20:43 ` [PATCH 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL Davidlohr Bueso
2014-06-03 19:26 ` Davidlohr Bueso
2014-09-23 5:24 ` Michael Kerrisk (man-pages) [this message]
2014-09-24 8:02 ` Davidlohr Bueso
-- strict thread matches above, loose matches on Subject: below --
2014-04-19 11:43 Manfred Spraul
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=54210407.1000602@gmail.com \
--to=mtk.manpages@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=aswin@hp.com \
--cc=dave@stgolabs.net \
--cc=davidlohr.bueso@hp.com \
--cc=gthelen@google.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=manfred@colorfullife.com \
--cc=schwidefsky@de.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).