Re: Changing SEMVMX to a tunable parameter

[Arvind Kandhare]

 >>How?
 > > SEMVMX is right now 32k, because the value is stored in an signed
 > > short,
 > > both internally and in the SuSv2 ABI.

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.

 > >
 > > Do you have an application that needs larger values?

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.

 > >What about other unices? Which value to they have for SEMVMX?

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