Re: Tuning up semaphores in kernel
On Sun, 13 Feb 19100, Andrey Novikov wrote: You probably want to increase either SEMMNI or SEMMNS. I've noticed that but why are they so "round"? Is there any corelation between all these numbers? I don't want to break my kernel by guessing. options SEMMAP=31 options SEMMNI=11 options SEMMNS=61 options SEMMNU=31 options SEMMSL=61 options SEMOPM=101 options SEMUME=11 I ran into this problem when I was trying to compile and use a useful Linux audio application and I got the ENOSPC error. What I did was to look at the Linux kernel semaphore values, and, since I don't know what I'm doing, I just plugged them into the FreeBSD kernel config file like this... (The values given as examples in the config file are one more than the default, and do not work with that program either) #! options SEMMAP=31 #! options SEMMNI=11 #! options SEMMNS=61 #! options SEMMNU=31 #! options SEMMSL=61 #! options SEMOPM=101 #! options SEMUME=11 options SEMMAP=4096 options SEMMNI=128 options SEMMNS=4096 options SEMMNU=4096 options SEMMSL=32 options SEMOPM=32 options SEMUME=32 Of course, seeing that I do *not* know what I am doing, I haven't played with these values to find a happy medium between the FreeBSD defaults and those used by Linux, with which the audio program works. But I have had no problems with the kernel using these values. Now, I'd like to contribute the hacking and bugfixing I've done on the linux bplay program to someone for review and possible inclusion as a port, but if it doesn't work with the supplied kernel and generic config, I'm not sure what the correct action for me to take would be. Is there a good reason not to tweak the GENERIC/LINT FreeBSD kernel config SEM* definitions upwards to something that will allow the bplay to work out-of-the-box^H^H^Hport? Or should there just be a huge BLINKwarning/BLINK that appears when building bplay advising that certain kernel parameters may need tuning before the program has a chance of working, during the compilation/installation, or just somewhere in the ports files where it can be ignored? Otherwise, I can't see that bplay would be particularly useful as a port, but rather as additional software the user could optionally choose to hunt down and install... thanks, barry bouwsma, tele damnark internet -- *** This was posted with the express permission of *** ** ** HIS HIGHNESS KAAZMANN LORD AND MASTER OF USENET ** ** * We are simple servants of his will * To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Tuning up semaphores in kernel
In article [EMAIL PROTECTED] you write: On Sun, 13 Feb 19100, Andrey Novikov wrote: You probably want to increase either SEMMNI or SEMMNS. I've noticed that but why are they so "round"? Is there any corelation between all these numbers? I don't want to break my kernel by guessing. options SEMMAP=31 options SEMMNI=11 options SEMMNS=61 options SEMMNU=31 options SEMMSL=61 options SEMOPM=101 options SEMUME=11 I ran into this problem when I was trying to compile and use a useful Linux audio application and I got the ENOSPC error. ... Now, I'd like to contribute the hacking and bugfixing I've done on the linux bplay program to someone for review and possible inclusion as a port, but if it doesn't work with the supplied kernel and generic config, I'm not sure what the correct action for me to take would be. hmm bplay, this is probably the original source that was used with some changes for gramofile, for which i already just submitted a port... (ports/16819, there its called play_gramo.) i simply patched it to use FreeBSD's default number. (If its not committed yet try the query-pr.cgi, or searching for gramofile in *freebsd.ports* on deja.com should also turn it up.) Is there a good reason not to tweak the GENERIC/LINT FreeBSD kernel config SEM* definitions upwards to something that will allow the bplay to work out-of-the-box^H^H^Hport? so its not necessary for bplay, the only justification for this i could think of would be to be able to run linux binaries without recompiling... Or should there just be a huge BLINKwarning/BLINK that appears when building bplay advising that certain kernel parameters may need tuning before the program has a chance of working, during the compilation/installation, or just somewhere in the ports files where it can be ignored? Otherwise, I can't see that bplay would be particularly useful as a port, but rather as additional software the user could optionally choose to hunt down and install... no even if a port won't work with the default kernel for some reason its still useful as a port, tho it probably should then have a pkg/MESSAGE telling the admin what he needs to put into the kernel. HTH, -- Juergen Lock [EMAIL PROTECTED] (remove dot foo from address to reply) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Tuning up semaphores in kernel
struct seminfo seminfo = {
SEMMAP, /* # of entries in semaphore map */
SEMMNI, /* # of semaphore identifiers */
SEMMNS, /* # of semaphores in system */
SEMMNU, /* # of undo structures in system */
SEMMSL, /* max # of semaphores per id */
SEMOPM, /* max # of operations per semop call */
SEMUME, /* max # of undo entries per process */
SEMUSZ, /* size in bytes of undo structure */
SEMVMX, /* semaphore maximum value */
SEMAEM /* adjust on exit max value */
};
You probably want to increase either SEMMNI or SEMMNS.
I've noticed that but why are they so "round"? Is there any corelation
between all these numbers? I don't want to break my kernel by guessing.
options SEMMAP=31
options SEMMNI=11
options SEMMNS=61
options SEMMNU=31
options SEMMSL=61
options SEMOPM=101
options SEMUME=11
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Tuning up semaphores in kernel
SEMMNI is the number of semaphore ids, i.e., the number of times you
can call 'semget()' without deleting any semaphores. SEMMNS is the
actual number of semaphores in the system, which should be = SEMMNI.
Of course, you can ask 'semget()' to give you up to SEMMSL semaphores
on each call, so SEMMNS should usually be larger than SEMMNI.
Ideally, if you know the max number of semaphores that a program
obtains via a semget call, set SEMMSL to that value. Then, if you
know the max number of semid's that are in use at any given time, then
set SEMMNI to that value. Then compute SEMMNS = SEMMNI*SEMMNS. This
will guarantee you have enough, as long as your usage information is
accurate.
Personally, I would just bump up SEMMNI and SEMMNS by 20% (or
whatever). Your documentation that came with your application should
give you an idea of it's semaphore usage. Use that as the guide as to
what to set these things to as a starting point.
-Brian
Andrey Novikov wrote:
struct seminfo seminfo = {
SEMMAP, /* # of entries in semaphore map */
SEMMNI, /* # of semaphore identifiers */
SEMMNS, /* # of semaphores in system */
SEMMNU, /* # of undo structures in system */
SEMMSL, /* max # of semaphores per id */
SEMOPM, /* max # of operations per semop call */
SEMUME, /* max # of undo entries per process */
SEMUSZ, /* size in bytes of undo structure */
SEMVMX, /* semaphore maximum value */
SEMAEM /* adjust on exit max value */
};
You probably want to increase either SEMMNI or SEMMNS.
I've noticed that but why are they so "round"? Is there any corelation
between all these numbers? I don't want to break my kernel by guessing.
options SEMMAP=31
options SEMMNI=11
options SEMMNS=61
options SEMMNU=31
options SEMMSL=61
options SEMOPM=101
options SEMUME=11
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Tuning up semaphores in kernel
Take a look at:
sys/conf/param.c:
/*
* Values in support of System V compatible semaphores.
*/
#ifdef SYSVSEM
struct seminfo seminfo = {
SEMMAP, /* # of entries in semaphore map */
SEMMNI, /* # of semaphore identifiers */
SEMMNS, /* # of semaphores in system */
SEMMNU, /* # of undo structures in system */
SEMMSL, /* max # of semaphores per id */
SEMOPM, /* max # of operations per semop call */
SEMUME, /* max # of undo entries per process */
SEMUSZ, /* size in bytes of undo structure */
SEMVMX, /* semaphore maximum value */
SEMAEM /* adjust on exit max value */
};
#endif
You probably want to increase either SEMMNI or SEMMNS.
Andrey Novikov wrote:
Resently my PostgreSQL daemon died with:
IpcSemaphoreCreate: semget failed (No space left on device) key=5432015, num=16,
permission=600
I figured out that the kernel is out of available semaphores,
I wanted to rebuild it but the problem is that the options
related to semaphores are not documented. This is the mission
critical commercial server so I don't want just to make assumptions.
Can you please tell me how these all enigmatic numbers are
properly choosed:
options SEMMAP=31
options SEMMNI=11
options SEMMNS=61
options SEMMNU=31
options SEMMSL=61
options SEMOPM=101
options SEMUME=11
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
