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

bugme-daemon at bugzilla.kernel.org bugme-daemon at bugzilla.kernel.org
Wed Aug 20 05:58:57 PDT 2008


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?


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


More information about the Bugme-new mailing list