lkml.org 
[lkml]   [2014]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[PATCH 0/3] ipc: Further updates to sysv/mqueue limits
Date
Hi all,

a) If we increase SHMMAX/SHMALL, then it makes sense to
increase MSGMNI, too.
And: This allows to remove the automatic scaling (~300 lines)

b) We can also increase SEMMSL, SEMMNI and SEMOPM

c) I think it would make more sense if a namespace starts with the
limits from it's parent:
If an admin set the limits, then he probably wants that these limits also
apply for a new child namespace.

All patches are RFC - they compile, but that's it.

TODO:
- check if the sysv sem limits are sane.
Especially the SEMOPM - if real users exist that pass > 1k ops, then
switch from kmalloc to vmalloc.

@the Redhat developers: Do you have any idea where this "often
recommended" comes from?
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Tuning_and_Optimizing_Red_Hat_Enterprise_Linux_for_Oracle_9i_and_10g_Databases/sect-Oracle_9i_and_10g_Tuning_Guide-Setting_Semaphores-The_SEMOPM_Parameter.html

- copy Davidlohrs explanation for the sysv shm limits to sysv msg and
sysv sem.

- check if we should also increase the limits for posix mqueue

- decide if it would make sense to increase IPCMNI:

Right now, it is 32768. This means that after 65536 pairs of
semget()/semctl(IPC_RMID), semget() will return the same identifier
again - and a semop(old_id) won't return -EINVAL, instead it will
access the "new" array, which is probably now what the caller
intended to do.

The split is arbitrary - we could also split it 1048576/2048 or any
other split we want.

- test everything.

--
Manfred


\
 
 \ /
  Last update: 2014-05-29 21:21    [W:0.097 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site