Re: Autotuning of kern.ipc.shmmaxpgs

[David Brownlee <abs%NetBSD.org@localhost>]

On Mon, 23 Feb 2009, Joerg Sonnenberger wrote:

> On Mon, Feb 23, 2009 at 02:56:49PM +0000, Mindaugas Rasiukevicius wrote:
> > Joerg Sonnenberger <joerg%britannica.bec.de@localhost> wrote:
> > > currently the maximum size of SysV shared memory is limited by a static
> > > MD limit. The attached patch allows platforms to not specify such a
> > > limit. If the kernel config doesn't specify one either, the kernel will
> > > compute a limit on startup based on physmem. Platforms with limited KVA
> > > can also set SHMMAX_AUTO_LIMIT, which places an upper boundary on the
> > > auto-tuned value.
> >
> > - I tend to think that removing MD definitions of SHMMAXPGS (or SHMMAX)
> >   would be the right thing to do.
>
> In general: yes.
>
> > - Why do you think KVA is the issue here?
>
> It is the only reason I can find for having a MD limit at all. If it is
> not considered an issue on things like VAX which can't grow the kernel
> map, I'm all for removing the static limits completely. Given that the
> shared memory segments are directly attached to to the process's vmmap,
> it should be irrelevant here.

        Would there be any sense in writing a test program to try to
        allocate as much SysV shared memory s possible, then get someone
        to test it as a non root user on a vax with the static limit
        completely removed. If it doesn't choke, then nuke the static
        limit altogether, otherwise maybe keep it as a MD define, but
        default it unset for everything and let ports set it if they
        find they need it (maybe add the test to atf).

--
                David/absolute       -- www.NetBSD.org: No hype required --