Changing SEMVMX to a tuneable parameter.

From: Arvind Kandhare (arvind.kan@wipro.com)
Date: Tue May 27 2003 - 03:46:27 EST


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



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/