From: Andrew Morton <akpm@linux-foundation.org>
To: Nadia Derbey <Nadia.Derbey@bull.net>
Cc: Solofo.Ramangalahy@bull.net, linux-kernel@vger.kernel.org,
matthltc@us.ibm.com, cmm@us.ibm.com, manfred@colorfullife.com,
nickpiggin@yahoo.com.au
Subject: Re: [PATCH -mm 1/3] sysv ipc: increase msgmnb default value wrt. the number of cpus
Date: Thu, 26 Jun 2008 09:12:16 -0700 [thread overview]
Message-ID: <20080626091216.e45099da.akpm@linux-foundation.org> (raw)
In-Reply-To: <4863AC5E.1070305@bull.net>
On Thu, 26 Jun 2008 16:49:02 +0200 Nadia Derbey <Nadia.Derbey@bull.net> wrote:
> >>+. If the value is positioned from user space to a negative value, then
> >>+ the computation is reenabled. E.g.
> >>+
> >>+ # echo -1 > /proc/sys/kernel/msgmnb
> >>+
> >>+See recompute_msgmnb() function in ipc/ directory for details.
> >>+The value of msgmnb is coupled with the value of msgmni.
> >>+
> >
> >
> > The magical positive-versus-negative number trick is a bit obscure, and
> > I don't think there's any precedent for it in the kernel ABI (which is
> > what this is).
> >
> > Is there anything we can do to reduce the unusualness of this
> > interface? Say, add a new /proc/sys/kernel/automatic-msgmnb which
> > contains the automatic scaling and leave /proc/sys/kernel/msgmnb
> > containing the manual scaling? Or something like that?
>
> Well, I don't know if I well understood your proposal: is it 1 value in
> automatic-msgmnb and another one in msgmnb?
> I don't clearly see how this could work.
>
> IMHO, we should keep /proc/sys/kernel/msgmnb as a way to externalize the
> current tunable value (whether it is automatically recomputed or not).
>
> Also keep the current strategy: as soon as a value is written into that
> file, give up with the automatic recomputing.
>
> And use the file you propose as a way to go back and forth between
> automatic recomputing and manual setting.
>
> So the process would be the following:
> 1) kernel boots in "automatic recomputing mode"
> /proc/kernel/sys/msgmni contains whatever value has been computed
> /proc/kernel/sys/automatic-msgmnb contains "ON"
>
> 2) echo <val> > /proc/kernel/sys/msgmnb
> . sets msg_ctlmnb to <val>
> . de-activates automatic recomputing (i.e. if, say, a cpu disappears
> it won't be recompiuted anymore)
> . /proc/kernel/sys/automatic-msgmnb now contains "OFF"
>
> Echoing "OFF" into /proc/kernel/sys/automatic-msgmnb would have the same
> effect (except that msg_ctlmnb's value would stay blocked at its current
> value)
>
> 3) echo "ON" > /proc/kernel/sys/automatic-msgmnb
> . recomputes msgmnb's value based on the current available resources
> . re-activates automatic recomputing for msgmnb.
>
> Of course, all this should be applied to msgmni too.
> And may be this automatic-xxx file should be located under sysfs?
> --> create /sys/kernel/automatic directory and have 1 file per
> tunable to be scalled (who knows, may be we are adding other ones in th
> future?)
>
> Now, may be this is what you actually proposed and I completely
> misunderstod it?
>
I don't know what I proposed, sorry ;) I didn't think about it very hard.
But the positive-values-mean-one-thing/negative-values-mean-another-thing
trick is unusual and rather unpleasing. I was hoping you guys could come up
with a cleaner interface.
next prev parent reply other threads:[~2008-06-26 16:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-24 9:34 [PATCH -mm 0/3] sysv ipc: increase msgmnb with the number of cpus Solofo.Ramangalahy
2008-06-24 9:34 ` [PATCH -mm 1/3] sysv ipc: increase msgmnb default value wrt. " Solofo.Ramangalahy
2008-06-24 21:31 ` Andrew Morton
2008-06-25 10:34 ` Nadia Derbey
2008-06-26 14:49 ` Nadia Derbey
2008-06-26 16:12 ` Andrew Morton [this message]
2008-06-24 9:34 ` [PATCH -mm 2/3] sysv ipc: recompute msgmnb (and msgmni) on cpu hotplug addition and removal Solofo.Ramangalahy
2008-06-24 9:34 ` [PATCH -mm 3/3] sysv ipc: deconnect msgmnb and msgmni deactivation and reactivation Solofo.Ramangalahy
2008-07-01 22:16 ` [PATCH -mm 0/3] sysv ipc: increase msgmnb with the number of cpus Andrew Morton
2008-07-03 5:39 ` Solofo.Ramangalahy
2008-07-03 12:05 ` Nadia Derbey
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=20080626091216.e45099da.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=Nadia.Derbey@bull.net \
--cc=Solofo.Ramangalahy@bull.net \
--cc=cmm@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=matthltc@us.ibm.com \
--cc=nickpiggin@yahoo.com.au \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox