linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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/

  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).