Semaphores in use require frequent access with very low overhead.
Having an expandable system in which the memory for each new requested semaphore structure is allocated on the fly will create complexity that will slow down access to them, because it will have to first search where the particular semaphore is currently stored, then go to memory where it is stored and check the value. It’s easier and faster to keep them in one compact block of fixed memory, which is easily at hand.
Having them scattered across memory through dynamic allocation also makes it difficult to efficiently use memory pages that are locked (that is, they cannot be exchanged for data with high memory requirements). Using "locked" memory pages for kernel data is especially important for time-sensitive and / or critical kernel functions.
The presence of a prefix - a custom parameter (see links in the comments of the original question) allows you to increase it at run time, if necessary, by means of an "expensive" redistribution and movement of the block. But usually this is done once during the initialization of the system, before something even with the help of semaphores.
However, the amount of memory used by the semaphore set is pretty tiny. With modern memory available on many gigabyte systems, the initial default limits for their number may seem a little mean. But keep in mind that semaphores are rarely used by user-space processes on many systems, and the linux kernel finds its way into many small embedded systems with fairly limited memory, so setting a default limit of arbitrarily large if it can be used, seems wasteful.
Several software packages, such as the Oracle database, for example, which are dependent on the availability of many semaphores, are usually recommended in their installation and / or system setup tips to increase system limits.
wojtow
source share