Changing SEMVMX to a tunable parameter

semval is a part of struct sem and it is an integer as of now (2.5.69). That is, it doesn't comply with SuS v3 as far as data type is concerned.

SuS v3 specifies semval to be an unsigned short.i.e. we can have a maximum of 64K on this.

Irrespective of the maximum value, an option to tune this limit would be highly desirable.

One example:
Oracle installation for some specific purposes (ref: http://www.cs.ndsu.nodak.edu/~vshi/cs366/OracleIns.pdf)

Will require this value to be tuned. As of now it requires a kernel re-build.

SEMVMX is one among the list of proposed tunable parameters we are
planning to implement.These when implemented, will allow Linux OS to be used for high end severs without kernel re-build.

Solaris, HP-Ux etc have this as a tunable parameter with maximum value as 64K.

Please refer ::
http://docs.sun.com/db/doc/816-7137/6md5pauj6?q=Tunable+parameters&a=view

PS: Kindly let us know your opinion on the design strategy (ref: previous mail appended).

Thanks and regards,
Arvind

Previous mail :::
Hi,

The following query is posted on LKML. Your valuable comments shall be highly appreciated.

From now on I'll CC such discussions to you when I mail LKML.

Thanks in advance,
Arvind

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

Ok, thus you want to increase it from 32k to 64k, but not beyond, correct? You'd have to check that there are no hidden signed/unsigned assumptions in ipc/sem.c

_If_ there are no signed/unsigned problems and if Oracle wants 64K, then I would increase SEMVMX to 64K, without making it tunable. Dito for SEMAEM.

--
Manfred

1. Most of the IPC parameters (e.g. msgmni, msgmax, msgmnb , shmmni, shmmax) are tunables.

(Please refer :
http://web.gnu.walfield.org/mail-archive/linux-kernel-digest/1999-November/0020.html)

Was there any specific reason why semvmx was not made a tunable with the above set??

2. By having semvmx as tunable, administrator gets more flexibility in controlling the resource usage on the system:
a. By increasing this, it is possible to allow more processes to use the system resources controlled by a semaphore concurrently.

b. By decreasing this, the number of processes using the system resources controlled by a semaphore concurrently can be limited.

Tuning this value may be desirable so that system is run at optimum performance. We are working towards avoiding kernel re-build for any desired value of semvmx. This will be most desirable in enterprise systems.

Because of problems with dynamic tuning (ref first mail on the subject), static tuning (boot time) is proposed.

Please let us know your comments.

thanks and regards,
Arvind

Why not just implement it and let us take a look at it? It shouldn't be that far out. Nothing wrong with fully dynamic tuning in principle, though this stuff is pretty obscure. Just hammer it out and we'll see how it looks.

-- wli

Because I didn't see the need for making it tunable.

Changing semvmx has no effect on the resource usage: An integer occupies 4 bytes, a short 2 bytes, independant of it's value.

Review everything for signed/unsigned problems, then post your findings and a patch that increases the limit to 64k. The whole patch will be shorter than the "confidential" disclaimer at the end of your mails.

--
Manfred