Re: Changing SEMVMX to a tunable parameter
From: Arvind Kandhare (email@example.com)
Date: Wed May 28 2003 - 09:29:51 EST
> > 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
> > Do you have an application that needs larger values?
Oracle installation for some specific purposes
Will require this value to be tuned. As of now it requires a kernel
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
Please refer ::
PS: Kindly let us know your opinion on the design strategy (ref:
previous mail appended).
Thanks and regards,
Previous mail :::
The following query is posted on LKML. Your valuable comments shall be
From now on I'll CC such discussions to you when I mail LKML.
Thanks in advance,
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
Two alternatives are considered for making this limit tunable as
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
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
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
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
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,
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/