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