[Bugme-new] [Bug 11381] New: default shmmax

[Andrew Morton]

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Wed, 20 Aug 2008 05:58:57 -0700 (PDT)
bugme-daemon at bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=11381
> 
>            Summary: default shmmax
>            Product: Other
>            Version: 2.5
>      KernelVersion: 2.6.26.2
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: enhancement
>           Priority: P1
>          Component: Other
>         AssignedTo: other_other at kernel-bugs.osdl.org
>         ReportedBy: peter_e at gmx.net
> 
> 
> I would like to request that the default shmmax setting be increased or the
> downsides of that be documented.  Allow me to explain.
> 
> I am with the PostgreSQL development team.  PostgreSQL is probably one of the
> few users of large amounts of SysV shared memory.  Users would usually want to
> configure anywhere between 10% and 50% of their physical RAM to be used as
> shared memory, which would translate to something on the order of gigabytes
> nowadays.  One of the uniformly annoying things about setting this up is that
> you need to reconfigure the Linux kernel to allow that.  sysctl is nice and
> all, but it still requires users to learn about operating system and kernel
> details, requires root access, and distros don't handle sysctl uniformly
> either.  Maybe there is even a good reason for that, but I couldn't find it,
> and at least I would like to learn it, so that we can pass that information on
> to our users.
> 
> I did some kernel version archeology and found out that up until kernels 2.2
> the shmmax setting appears to have been restricted by CPU-specific constraints,
> as indicated by the default setting being different across CPUs and being
> defined in an asm header.  The default setting on i386 was increased from 16 MB
> to 32 MB somewhere around 1998 in the kernel 2.0 line, and it remains at 32 MB
> in the latest kernel on all architectures.
> 
> Now one question is whether there is a space or time overhead involved with
> setting a high shmmax limit that isn't actually used.  If so, it would be
> interesting to know what that overhead is.  The feeling I get from browsing the
> kernel source code over time is that there was some management overhead and/or
> some restrictions about this in old kernels, but that nowadays it doesn't
> really seem to matter much anymore.  I suspect instead that this whole thing
> was just forgotten, because few applications use large amounts of shared
> memory.
> 
> So, if you want to do us a favor, could you please see about increasing the
> default shmmax setting to whatever the theoretical maximum is?
> 

I don't think anybody has even thought about the shmmax default in
years.  Sure, it might be time to reexamine that.

It would be useful to get distro input on this.  Do they override the
kernel default at boot time?  If so, what do they do?


Also, from a quick read it looks to me that shmmax is busted in the
non-init namespace.

clone_ipc_ns() calls shm_init_ns() which does

	ns->shm_ctlmax = SHMMAX;

which a) fails to inherit the parent's setting and b) cannot be altered
from SHMMAX via the sysctl?