Re: Changing SEMVMX to a tunable parameter

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

Re: Changing SEMVMX to a tunable parameter

[Manfred Spraul]

Arvind Kandhare wrote:

>
> >>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.

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

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

_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

Re: Changing SEMVMX to a tunable parameter

[Arvind Kandhare]

Manfred Spraul wrote:
> _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.
> 

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

Re: Changing SEMVMX to a tunable parameter

[William Lee Irwin III]

On Thu, May 29, 2003 at 03:47:45PM +0530, Arvind Kandhare wrote:
> 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.

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

Re: Changing SEMVMX to a tunable parameter

[Manfred Spraul]

Arvind Kandhare wrote:

>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??  
>  
>
Because I didn't see the need for making it tunable.

>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.
>  
>
Changing semvmx has no effect on the resource usage: An integer occupies 
4 bytes, a short 2 bytes, independant of it's value.

>Because of problems with dynamic tuning (ref first mail on the subject), 
>static tuning (boot time) is proposed.
>
>Please let us know your comments.
>  
>
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