We are planning to implement a set of Kernel Tunable Parameters and one
of these paramters is semvmx for IPC semaphores.
The existing SEMVMX is hash defined as 32768. We intend to make this a
tunable parameter.
Two alternatives are considered for making this limit tunable as
explained below.
A) Dynamically Tunable using /proc/sys interface.
Proposed implementation is to replace the hash defined SEMVMX in
try_atomic_semop (), semctl_main () and semctl_nolock () by the
configurable value.
This check returns -ERANGE if the current value of semaphore is more
than semvmx limit. *but* there are some logical inconsistancies if
semvmx limit is dynamically reduced below the value of the semaphore
(semval). They are :
1. Releasing the semaphore may fail whereas acquiring has gone
through.This is due to the existing check of semval against the limit in
try_atomic_semop ().
2. Acquiring a semaphore may fail even if the semval > 0:
If the resultant semaphore value (semval) after an acquire stays
above the limit,the check and hence acquire operation fails.
To Overcome these problems following approaches may be considered:
1. Apply the check against the tuned limit only in semctl_main () call.
If semctl and semop can be used interchangably to change the value of
the semaphore this approach will not work.
2. Apply check only when +ve semop is done. So acquiring and
decrementing the value will never fail. This approach solves the second
inconsistency but first one will prevail.
3. Retain similar/same checks against the tuned limit and return an
error to the caller on any inconsistancy (as mentioned in points 1 & 2
above).
A cleaner solution would be:
B) Statically Tunable using boot time parameter:
Most important problem with dynamic tuneability is on a possible
reduction of the limit when the system runs.Most of these could be
avoided if sysadmin is not permitted to modify this limit
dynamically.For this we can make this a static parameter.
A frame work for static tuning of parameters is not directly supported
in Linux.
We propose to make it a boot time tuneable (with boot time command line
interface). This limit can be viewed through /proc/sys interface as a
read only parameter.
Though we loose slightly on flexibility to change this value (possible
only at boot time), we gain on better run-time consistancies with a
static implementation.
Please let us know your suggestions on above alternatives.
Note: We are planning to implement SEMAEM also as a tuneable parameter.
A conclusion on above shall be considered while designing the same also.
Thanks and regards,
Arvind