Re: increasing sysv semaphore limits

On Wed, Jul 15, 2026 at 03:48:38PM +0000, Taylor R Campbell wrote:
> > Date: Wed, 15 Jul 2026 11:42:00 -0400
> > From: Greg Troxel <[email protected]>
[..]
> >   I propose to change SEMMNI from 10 to 32.
> >   I propose to change SEMMNS from 60 to 256.
> > 
> > The concept would be, as it is now, that individual ports or kernel
> > configs could just set these to lower values, if that's appropriate.
> 
> Why not vary automatically with the amount of RAM at boot?

This could be done with a few #ifdef tricks. The numbers in struct seminfo
are all int32_t, so we could init them to -1 unless the option is defined
and overrides it, like:

/*
 * Values in support of System V compatible semaphores.
 */
#ifdef SYSVSEM
struct  seminfo seminfo = {
#ifdef SEMMAP
        SEMMAP,         /* # of entries in semaphore map */
#else
	-1,
#endif
#ifdef SEMMNI
        SEMMNI,         /* # of semaphore identifiers */
#else
	-1,
#endif
#ifdef SEMMNS
        SEMMNS,         /* # of semaphores in system */
#else
	-1,
#endif
....


and then check for -1 in seminit() and set up a value based on available
RAM and KVA.

To get a concrete idea of what we are talking about, here are the 
sizes on amd64:

        /* Allocate the wired memory for our structures */
        sz = ALIGN(seminfo.semmni * sizeof(struct semid_ds)) +
            ALIGN(seminfo.semmns * sizeof(struct __sem)) +
            ALIGN(seminfo.semmni * sizeof(kcondvar_t)) +
            ALIGN(seminfo.semmnu * seminfo.semusz);
        sz = round_page(sz);

and:
(gdb) p sizeof(struct semid_ds)
$2 = 64
(gdb) p sizeof(struct __sem)
$3 = 12
(gdb) p sizeof(kcondvar_t)
$4 = 16

so the suggested change costs 22*64 + 196*12 = 3760 bytes
plus maybe a bit of alignment - so 1 more wired page most likely.

However, most machines never need it (or not much of it), so I wonder if
we could (relatively simple) init it on first use only (and then maybe
scaled by KVA/RAM details).

Martin