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