From: Manfred Spraul <manfred@colorfullife.com>
To: arvind.kan@wipro.com
Cc: William Lee Irwin III <wli@holomorphy.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
akpm@digeo.com, "indou.takao" <indou.takao@jp.fujitsu.com>,
Dave Jones <davej@suse.de>
Subject: Re: [RFC][PATCH 2.5.70] Static tunable semvmx and semaem
Date: Fri, 06 Jun 2003 18:52:29 +0200 [thread overview]
Message-ID: <3EE0C6CD.4000407@colorfullife.com> (raw)
In-Reply-To: <3EE02C53.1040800@wipro.com>
Arvind Kandhare wrote:
>
> Hi,
> Please find below patch(RFC) for implementing semvmx and semaem
> as static tunable parameters.
>
Have you thought about signed/unsigned issues? Which unix permits values
> 32767? Are there any potential user space problems?
I did a quick google search, and found this:
http://www.core-software.ch/samples/www/SunFire_3800/SunFire_3800.pdf,
i.e. Solaris 2.x:
<<
SEMVMX 32767 Limits the maximum value of a semaphore. Due to the
interaction with undo structures and semaem (see below), this tunable
should not be increased beyond its default value of 32767, unless you
can guarantee that SEM_UNDO is never and will never be used. It can be
safely reduced, but doing so provides no savings.
SEMAEM 16384 Limits the maximum value of an adjust-on-exit undo element.
No system resources are allocated based on this value.
<<
And as I wrote, I'd prefer a patch that just does s/32767/65535/ -
either it is safe, or it's unsafe. If it's unsafe, then it should remain
at 32767. If it safe, then we can increase it unconditionally, because a
reduction below the upper limit provides no savings.
--
Manfred
next prev parent reply other threads:[~2003-06-06 16:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-06 5:53 [RFC][PATCH 2.5.70] Static tunable semvmx and semaem Arvind Kandhare
2003-06-06 6:50 ` William Lee Irwin III
2003-06-06 9:01 ` Arvind Kandhare
2003-06-06 13:12 ` William Lee Irwin III
2003-06-06 16:52 ` Manfred Spraul [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-06-06 15:02 Arvind Kandhare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3EE0C6CD.4000407@colorfullife.com \
--to=manfred@colorfullife.com \
--cc=akpm@digeo.com \
--cc=arvind.kan@wipro.com \
--cc=davej@suse.de \
--cc=indou.takao@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=wli@holomorphy.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.