lkml.org 
[lkml]   [2014]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] ipc,shm: increase default size for shmmax
    On Mon, 31 Mar 2014 15:59:33 -0700 Davidlohr Bueso <davidlohr@hp.com> wrote:

    > >
    > > - Shouldn't there be a way to alter this namespace's shm_ctlmax?
    >
    > Unfortunately this would also add the complexity I previously mentioned.

    But if the current namespace's shm_ctlmax is too small, you're screwed.
    Have to shut down the namespace all the way back to init_ns and start
    again.

    > > - What happens if we just nuke the limit altogether and fall back to
    > > the next check, which presumably is the rlimit bounds?
    >
    > afaik we only have rlimit for msgqueues. But in any case, while I like
    > that simplicity, it's too late. Too many workloads (specially DBs) rely
    > heavily on shmmax. Removing it and relying on something else would thus
    > cause a lot of things to break.

    It would permit larger shm segments - how could that break things? It
    would make most or all of these issues go away?



    First principles: why does this thing exist? What problem was SHMMAX
    created to solve? It doesn't appear to be part of posix:

    http://pubs.opengroup.org/onlinepubs/000095399/functions/shmget.html

    [ENOMEM]
    A shared memory identifier and associated shared memory segment
    shall be created, but the amount of available physical memory is
    not sufficient to fill the request.



    \
     
     \ /
      Last update: 2014-04-01 02:01    [W:5.285 / U:0.132 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site