Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Linux>
  3. Kernel
1 2  View All
[PATCH 1/8] Scaling msgmni to the amount of lowmem
Nadia.Derbey at bull
Feb 11, 2008, 6:16 AM
Post #1 of 26 (1154 views)
Permalink
[PATCH 01/08]

This patch computes msg_ctlmni to make it scale with the amount of lowmem.
msg_ctlmni is now set to make the message queues occupy 1/32 of the available
lowmem.

Some cleaning has also been done for the MSGPOOL constant: the msgctl man page
says it's not used, but it also defines it as a size in bytes (the code
expresses it in Kbytes).

Signed-off-by: Nadia Derbey <Nadia.Derbey@bull.net>

---
include/linux/msg.h | 14 ++++++++++++--
ipc/msg.c | 37 ++++++++++++++++++++++++++++++++++++-
2 files changed, 48 insertions(+), 3 deletions(-)

Index: linux-2.6.24-mm1/include/linux/msg.h
===================================================================
--- linux-2.6.24-mm1.orig/include/linux/msg.h 2008-02-07 15:01:38.000000000 +0100
+++ linux-2.6.24-mm1/include/linux/msg.h 2008-02-07 15:23:17.000000000 +0100
@@ -49,16 +49,26 @@ struct msginfo {
unsigned short msgseg;
};

+/*
+ * Scaling factor to compute msgmni:
+ * the memory dedicated to msg queues (msgmni * msgmnb) should occupy
+ * at most 1/MSG_MEM_SCALE of the lowmem (see the formula in ipc/msg.c):
+ * up to 8MB : msgmni = 16 (MSGMNI)
+ * 4 GB : msgmni = 8K
+ * more than 16 GB : msgmni = 32K (IPCMNI)
+ */
+#define MSG_MEM_SCALE 32
+
#define MSGMNI 16 /* <= IPCMNI */ /* max # of msg queue identifiers */
#define MSGMAX 8192 /* <= INT_MAX */ /* max size of message (bytes) */
#define MSGMNB 16384 /* <= INT_MAX */ /* default max size of a message queue */

/* unused */
-#define MSGPOOL (MSGMNI*MSGMNB/1024) /* size in kilobytes of message pool */
+#define MSGPOOL (MSGMNI * MSGMNB) /* size in bytes of message pool */
#define MSGTQL MSGMNB /* number of system message headers */
#define MSGMAP MSGMNB /* number of entries in message map */
#define MSGSSZ 16 /* message segment size */
-#define __MSGSEG ((MSGPOOL*1024)/ MSGSSZ) /* max no. of segments */
+#define __MSGSEG (MSGPOOL / MSGSSZ) /* max no. of segments */
#define MSGSEG (__MSGSEG <= 0xffff ? __MSGSEG : 0xffff)

#ifdef __KERNEL__
Index: linux-2.6.24-mm1/ipc/msg.c
===================================================================
--- linux-2.6.24-mm1.orig/ipc/msg.c 2008-02-07 15:02:29.000000000 +0100
+++ linux-2.6.24-mm1/ipc/msg.c 2008-02-07 15:24:19.000000000 +0100
@@ -27,6 +27,7 @@
#include <linux/msg.h>
#include <linux/spinlock.h>
#include <linux/init.h>
+#include <linux/mm.h>
#include <linux/proc_fs.h>
#include <linux/list.h>
#include <linux/security.h>
@@ -78,11 +79,45 @@ static int newque(struct ipc_namespace *
static int sysvipc_msg_proc_show(struct seq_file *s, void *it);
#endif

+/*
+ * Scale msgmni with the available lowmem size: the memory dedicated to msg
+ * queues should occupy at most 1/MSG_MEM_SCALE of lowmem.
+ * This should be done staying within the (MSGMNI , IPCMNI) range.
+ */
+static void recompute_msgmni(struct ipc_namespace *ns)
+{
+ struct sysinfo i;
+ unsigned long allowed;
+
+ si_meminfo(&i);
+ allowed = (((i.totalram - i.totalhigh) / MSG_MEM_SCALE) * i.mem_unit)
+ / MSGMNB;
+
+ if (allowed < MSGMNI) {
+ ns->msg_ctlmni = MSGMNI;
+ goto out_callback;
+ }
+
+ if (allowed > IPCMNI) {
+ ns->msg_ctlmni = IPCMNI;
+ goto out_callback;
+ }
+
+ ns->msg_ctlmni = allowed;
+
+out_callback:
+
+ printk(KERN_INFO "msgmni has been set to %d for ipc namespace %p\n",
+ ns->msg_ctlmni, ns);
+}
+
void msg_init_ns(struct ipc_namespace *ns)
{
ns->msg_ctlmax = MSGMAX;
ns->msg_ctlmnb = MSGMNB;
- ns->msg_ctlmni = MSGMNI;
+
+ recompute_msgmni(ns);
+
atomic_set(&ns->msg_bytes, 0);
atomic_set(&ns->msg_hdrs, 0);
ipc_init_ids(&ns->ids[IPC_MSG_IDS]);

--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
akpm at linux-foundation
Feb 15, 2008, 9:59 PM
Post #2 of 26 (1129 views)
Permalink
On Mon, 11 Feb 2008 15:16:47 +0100 Nadia.Derbey@bull.net wrote:

> [PATCH 01/08]
>
> This patch computes msg_ctlmni to make it scale with the amount of lowmem.
> msg_ctlmni is now set to make the message queues occupy 1/32 of the available
> lowmem.
>
> Some cleaning has also been done for the MSGPOOL constant: the msgctl man page
> says it's not used, but it also defines it as a size in bytes (the code
> expresses it in Kbytes).
>

Something's wrong here. Running LTP's msgctl08 (specifically:
ltp-full-20070228) cripples the machine. It's a 4-way 4GB x86_64.

http://userweb.kernel.org/~akpm/config-x.txt
http://userweb.kernel.org/~akpm/dmesg-x.txt

Normally msgctl08 will complete in a second or two. With this patch I
don't know how long it will take to complete, and the machine is horridly
bogged down. It does recover if you manage to kill msgctl08. Feels like
a terrible memory shortage, but there's plenty of memory free and it isn't
swapping.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
Nadia.Derbey at bull
Feb 18, 2008, 1:19 AM
Post #3 of 26 (1122 views)
Permalink
Andrew Morton wrote:
> On Mon, 11 Feb 2008 15:16:47 +0100 Nadia.Derbey@bull.net wrote:
>
>
>>[PATCH 01/08]
>>
>>This patch computes msg_ctlmni to make it scale with the amount of lowmem.
>>msg_ctlmni is now set to make the message queues occupy 1/32 of the available
>>lowmem.
>>
>>Some cleaning has also been done for the MSGPOOL constant: the msgctl man page
>>says it's not used, but it also defines it as a size in bytes (the code
>>expresses it in Kbytes).
>>
>
>
> Something's wrong here. Running LTP's msgctl08 (specifically:
> ltp-full-20070228) cripples the machine. It's a 4-way 4GB x86_64.
>
> http://userweb.kernel.org/~akpm/config-x.txt
> http://userweb.kernel.org/~akpm/dmesg-x.txt
>
> Normally msgctl08 will complete in a second or two. With this patch I
> don't know how long it will take to complete, and the machine is horridly
> bogged down. It does recover if you manage to kill msgctl08. Feels like
> a terrible memory shortage, but there's plenty of memory free and it isn't
> swapping.
>
>
>

Before the patchset, msgctl08 used to be run with the old msgmni value:
16. Now it is run with a much higher msgmni value (1746 in my case),
since it scales to the memory size.
When I call "msgctl08 100000 16" it completes fast.

Doing the follwing on the ref kernel:
echo 1746 > /proc/sys/kernel/msgmni
msgctl08 100000 1746

makes th test block too :-(

Will check to see where the problem comes from.

Rgards,
Nadia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
Nadia.Derbey at bull
Feb 18, 2008, 5:08 AM
Post #4 of 26 (1123 views)
Permalink
Nadia Derbey wrote:
> Andrew Morton wrote:
>
>> On Mon, 11 Feb 2008 15:16:47 +0100 Nadia.Derbey@bull.net wrote:
>>
>>
>>> [PATCH 01/08]
>>>
>>> This patch computes msg_ctlmni to make it scale with the amount of
>>> lowmem.
>>> msg_ctlmni is now set to make the message queues occupy 1/32 of the
>>> available
>>> lowmem.
>>>
>>> Some cleaning has also been done for the MSGPOOL constant: the msgctl
>>> man page
>>> says it's not used, but it also defines it as a size in bytes (the code
>>> expresses it in Kbytes).
>>>
>>
>>
>> Something's wrong here. Running LTP's msgctl08 (specifically:
>> ltp-full-20070228) cripples the machine. It's a 4-way 4GB x86_64.
>>
>> http://userweb.kernel.org/~akpm/config-x.txt
>> http://userweb.kernel.org/~akpm/dmesg-x.txt
>>
>> Normally msgctl08 will complete in a second or two. With this patch I
>> don't know how long it will take to complete, and the machine is horridly
>> bogged down. It does recover if you manage to kill msgctl08. Feels like
>> a terrible memory shortage, but there's plenty of memory free and it
>> isn't
>> swapping.
>>
>>
>>
>
> Before the patchset, msgctl08 used to be run with the old msgmni value:
> 16. Now it is run with a much higher msgmni value (1746 in my case),
> since it scales to the memory size.
> When I call "msgctl08 100000 16" it completes fast.
>
> Doing the follwing on the ref kernel:
> echo 1746 > /proc/sys/kernel/msgmni
> msgctl08 100000 1746
>
> makes th test block too :-(
>
> Will check to see where the problem comes from.
>

Well, actually, the test does not block, it only takes much much more
time to be executed:

doing this:
date; ./msgctl08 100000 XXX; date


gives us the following results:
XXX 16 32 64 128 256 512 1024 1746
time(secs) 2 4 8 16 32 64 132 241

XXX is the # of msg queues to be created = # of processes to be forked
as readers = # of processes to be created as writers
time is approximative since it is obtained by a "date" before and after.

XXX used to be 16 before the patchset ---> 1st column
--> 16 processes forked as reader
--> + 16 processes forked as writers
--> + 16 msg queues
XXX = 1746 (on my victim) after the patchset ---> last column
--> 1746 reader processes forked
--> + 1746 writers forked
--> + 1746 msg queues created

The same tests on the ref kernel give approximatly the same results.

So if we don't want this longer time to appear as a regression, the LTP
should be changed:
1) either by setting the result of get_max_msgqueues() as the MSGMNI
constant (16) (that would be the best solution in my mind)
2) or by warning the tester that it may take a long time to finish.

There would be 3 tests impacted:

kernel/syscalls/ipc/msgctl/msgctl08.c
kernel/syscalls/ipc/msgctl/msgctl09.c
kernel/syscalls/ipc/msgget/msgget03.c

Cc-ing ltp mailing list ...

Regards,
Nadia


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LTP] [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
subrata at linux
Feb 19, 2008, 12:50 AM
Post #5 of 26 (1122 views)
Permalink
> Nadia Derbey wrote:
> > Andrew Morton wrote:
> >
> >> On Mon, 11 Feb 2008 15:16:47 +0100 Nadia.Derbey@bull.net wrote:
> >>
> >>
> >>> [PATCH 01/08]
> >>>
> >>> This patch computes msg_ctlmni to make it scale with the amount of
> >>> lowmem.
> >>> msg_ctlmni is now set to make the message queues occupy 1/32 of the
> >>> available
> >>> lowmem.
> >>>
> >>> Some cleaning has also been done for the MSGPOOL constant: the msgctl
> >>> man page
> >>> says it's not used, but it also defines it as a size in bytes (the code
> >>> expresses it in Kbytes).
> >>>
> >>
> >>
> >> Something's wrong here. Running LTP's msgctl08 (specifically:
> >> ltp-full-20070228) cripples the machine. It's a 4-way 4GB x86_64.
> >>
> >> http://userweb.kernel.org/~akpm/config-x.txt
> >> http://userweb.kernel.org/~akpm/dmesg-x.txt
> >>
> >> Normally msgctl08 will complete in a second or two. With this patch I
> >> don't know how long it will take to complete, and the machine is horridly
> >> bogged down. It does recover if you manage to kill msgctl08. Feels like
> >> a terrible memory shortage, but there's plenty of memory free and it
> >> isn't
> >> swapping.
> >>
> >>
> >>
> >
> > Before the patchset, msgctl08 used to be run with the old msgmni value:
> > 16. Now it is run with a much higher msgmni value (1746 in my case),
> > since it scales to the memory size.
> > When I call "msgctl08 100000 16" it completes fast.
> >
> > Doing the follwing on the ref kernel:
> > echo 1746 > /proc/sys/kernel/msgmni
> > msgctl08 100000 1746
> >
> > makes th test block too :-(
> >
> > Will check to see where the problem comes from.
> >
>
> Well, actually, the test does not block, it only takes much much more
> time to be executed:
>
> doing this:
> date; ./msgctl08 100000 XXX; date
>
>
> gives us the following results:
> XXX 16 32 64 128 256 512 1024 1746
> time(secs) 2 4 8 16 32 64 132 241
>
> XXX is the # of msg queues to be created = # of processes to be forked
> as readers = # of processes to be created as writers
> time is approximative since it is obtained by a "date" before and after.
>
> XXX used to be 16 before the patchset ---> 1st column
> --> 16 processes forked as reader
> --> + 16 processes forked as writers
> --> + 16 msg queues
> XXX = 1746 (on my victim) after the patchset ---> last column
> --> 1746 reader processes forked
> --> + 1746 writers forked
> --> + 1746 msg queues created
>
> The same tests on the ref kernel give approximatly the same results.
>
> So if we don't want this longer time to appear as a regression, the LTP
> should be changed:
> 1) either by setting the result of get_max_msgqueues() as the MSGMNI
> constant (16) (that would be the best solution in my mind)
> 2) or by warning the tester that it may take a long time to finish.
>
> There would be 3 tests impacted:
>
> kernel/syscalls/ipc/msgctl/msgctl08.c
> kernel/syscalls/ipc/msgctl/msgctl09.c
> kernel/syscalls/ipc/msgget/msgget03.c

We will change the test case if need that be. Nadia, kindly send us the
patch set which will do the necessary changes.

Regards--
Subrata

>
> Cc-ing ltp mailing list ...
>
> Regards,
> Nadia
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LTP] [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
Nadia.Derbey at bull
Feb 19, 2008, 9:16 AM
Post #6 of 26 (1121 views)
Permalink
Subrata Modak wrote:
>>Nadia Derbey wrote:
>>
>>>Andrew Morton wrote:
>>>
>>>
>>>>On Mon, 11 Feb 2008 15:16:47 +0100 Nadia.Derbey@bull.net wrote:
>>>>
>>>>
>>>>
>>>>>[PATCH 01/08]
>>>>>
>>>>>This patch computes msg_ctlmni to make it scale with the amount of
>>>>>lowmem.
>>>>>msg_ctlmni is now set to make the message queues occupy 1/32 of the
>>>>>available
>>>>>lowmem.
>>>>>
>>>>>Some cleaning has also been done for the MSGPOOL constant: the msgctl
>>>>>man page
>>>>>says it's not used, but it also defines it as a size in bytes (the code
>>>>>expresses it in Kbytes).
>>>>>
>>>>
>>>>
>>>>Something's wrong here. Running LTP's msgctl08 (specifically:
>>>>ltp-full-20070228) cripples the machine. It's a 4-way 4GB x86_64.
>>>>
>>>>http://userweb.kernel.org/~akpm/config-x.txt
>>>>http://userweb.kernel.org/~akpm/dmesg-x.txt
>>>>
>>>>Normally msgctl08 will complete in a second or two. With this patch I
>>>>don't know how long it will take to complete, and the machine is horridly
>>>>bogged down. It does recover if you manage to kill msgctl08. Feels like
>>>>a terrible memory shortage, but there's plenty of memory free and it
>>>>isn't
>>>>swapping.
>>>>
>>>>
>>>>
>>>
>>>Before the patchset, msgctl08 used to be run with the old msgmni value:
>>>16. Now it is run with a much higher msgmni value (1746 in my case),
>>>since it scales to the memory size.
>>>When I call "msgctl08 100000 16" it completes fast.
>>>
>>>Doing the follwing on the ref kernel:
>>>echo 1746 > /proc/sys/kernel/msgmni
>>>msgctl08 100000 1746
>>>
>>>makes th test block too :-(
>>>
>>>Will check to see where the problem comes from.
>>>
>>
>>Well, actually, the test does not block, it only takes much much more
>>time to be executed:
>>
>>doing this:
>>date; ./msgctl08 100000 XXX; date
>>
>>
>>gives us the following results:
>>XXX 16 32 64 128 256 512 1024 1746
>>time(secs) 2 4 8 16 32 64 132 241
>>
>>XXX is the # of msg queues to be created = # of processes to be forked
>>as readers = # of processes to be created as writers
>>time is approximative since it is obtained by a "date" before and after.
>>
>>XXX used to be 16 before the patchset ---> 1st column
>> --> 16 processes forked as reader
>> --> + 16 processes forked as writers
>> --> + 16 msg queues
>>XXX = 1746 (on my victim) after the patchset ---> last column
>> --> 1746 reader processes forked
>> --> + 1746 writers forked
>> --> + 1746 msg queues created
>>
>>The same tests on the ref kernel give approximatly the same results.
>>
>>So if we don't want this longer time to appear as a regression, the LTP
>>should be changed:
>>1) either by setting the result of get_max_msgqueues() as the MSGMNI
>>constant (16) (that would be the best solution in my mind)
>>2) or by warning the tester that it may take a long time to finish.
>>
>>There would be 3 tests impacted:
>>
>>kernel/syscalls/ipc/msgctl/msgctl08.c
>>kernel/syscalls/ipc/msgctl/msgctl09.c
>>kernel/syscalls/ipc/msgget/msgget03.c
>
>
> We will change the test case if need that be. Nadia, kindly send us the
> patch set which will do the necessary changes.
>
> Regards--
> Subrata
>

Subrata,

You'll find the patch in attachment.
FYI I didn't change msgget03.c since we need to get the actual max value
in order to generate an error.

Regards,
Nadia

Attached Files:

Re: [LTP] [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
matthltc at us
Feb 19, 2008, 2:16 PM
Post #7 of 26 (1118 views)
Permalink
On Tue, 2008-02-19 at 18:16 +0100, Nadia Derbey wrote:

<snip>

> +#define MAX_MSGQUEUES 16 /* MSGMNI as defined in linux/msg.h */
> +

It's not quite the maximum anymore, is it? More like the minumum
maximum ;). A better name might better document what the test is
actually trying to do.

One question I have is whether the unpatched test is still valuable.
Based on my limited knowledge of the test I suspect it's still a correct
test of message queues. If so, perhaps renaming the old test (so it's
not confused with a performance regression) and adding your patched
version is best?

<snip>

Cheers,
-Matt Helsley

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LTP] [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
subrata at linux
Feb 20, 2008, 1:44 AM
Post #8 of 26 (1123 views)
Permalink
> Subrata Modak wrote:
> >>Nadia Derbey wrote:
> >>
> >>>Andrew Morton wrote:
> >>>
> >>>
> >>>>On Mon, 11 Feb 2008 15:16:47 +0100 Nadia.Derbey@bull.net wrote:
> >>>>
> >>>>
> >>>>
> >>>>>[PATCH 01/08]
> >>>>>
> >>>>>This patch computes msg_ctlmni to make it scale with the amount of
> >>>>>lowmem.
> >>>>>msg_ctlmni is now set to make the message queues occupy 1/32 of the
> >>>>>available
> >>>>>lowmem.
> >>>>>
> >>>>>Some cleaning has also been done for the MSGPOOL constant: the msgctl
> >>>>>man page
> >>>>>says it's not used, but it also defines it as a size in bytes (the code
> >>>>>expresses it in Kbytes).
> >>>>>
> >>>>
> >>>>
> >>>>Something's wrong here. Running LTP's msgctl08 (specifically:
> >>>>ltp-full-20070228) cripples the machine. It's a 4-way 4GB x86_64.
> >>>>
> >>>>http://userweb.kernel.org/~akpm/config-x.txt
> >>>>http://userweb.kernel.org/~akpm/dmesg-x.txt
> >>>>
> >>>>Normally msgctl08 will complete in a second or two. With this patch I
> >>>>don't know how long it will take to complete, and the machine is horridly
> >>>>bogged down. It does recover if you manage to kill msgctl08. Feels like
> >>>>a terrible memory shortage, but there's plenty of memory free and it
> >>>>isn't
> >>>>swapping.
> >>>>
> >>>>
> >>>>
> >>>
> >>>Before the patchset, msgctl08 used to be run with the old msgmni value:
> >>>16. Now it is run with a much higher msgmni value (1746 in my case),
> >>>since it scales to the memory size.
> >>>When I call "msgctl08 100000 16" it completes fast.
> >>>
> >>>Doing the follwing on the ref kernel:
> >>>echo 1746 > /proc/sys/kernel/msgmni
> >>>msgctl08 100000 1746
> >>>
> >>>makes th test block too :-(
> >>>
> >>>Will check to see where the problem comes from.
> >>>
> >>
> >>Well, actually, the test does not block, it only takes much much more
> >>time to be executed:
> >>
> >>doing this:
> >>date; ./msgctl08 100000 XXX; date
> >>
> >>
> >>gives us the following results:
> >>XXX 16 32 64 128 256 512 1024 1746
> >>time(secs) 2 4 8 16 32 64 132 241
> >>
> >>XXX is the # of msg queues to be created = # of processes to be forked
> >>as readers = # of processes to be created as writers
> >>time is approximative since it is obtained by a "date" before and after.
> >>
> >>XXX used to be 16 before the patchset ---> 1st column
> >> --> 16 processes forked as reader
> >> --> + 16 processes forked as writers
> >> --> + 16 msg queues
> >>XXX = 1746 (on my victim) after the patchset ---> last column
> >> --> 1746 reader processes forked
> >> --> + 1746 writers forked
> >> --> + 1746 msg queues created
> >>
> >>The same tests on the ref kernel give approximatly the same results.
> >>
> >>So if we don't want this longer time to appear as a regression, the LTP
> >>should be changed:
> >>1) either by setting the result of get_max_msgqueues() as the MSGMNI
> >>constant (16) (that would be the best solution in my mind)
> >>2) or by warning the tester that it may take a long time to finish.
> >>
> >>There would be 3 tests impacted:
> >>
> >>kernel/syscalls/ipc/msgctl/msgctl08.c
> >>kernel/syscalls/ipc/msgctl/msgctl09.c
> >>kernel/syscalls/ipc/msgget/msgget03.c
> >
> >
> > We will change the test case if need that be. Nadia, kindly send us the
> > patch set which will do the necessary changes.
> >
> > Regards--
> > Subrata
> >
>
> Subrata,
>
> You'll find the patch in attachment.
> FYI I didn't change msgget03.c since we need to get the actual max value
> in order to generate an error.

Thanks. The same has been Merged.

Regards--
Subrata

>
> Regards,
> Nadia
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LTP] [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
Nadia.Derbey at bull
Feb 21, 2008, 12:39 AM
Post #9 of 26 (1115 views)
Permalink
Matt Helsley wrote:
> On Tue, 2008-02-19 at 18:16 +0100, Nadia Derbey wrote:
>
> <snip>
>
>>+#define MAX_MSGQUEUES 16 /* MSGMNI as defined in linux/msg.h */
>>+
>
>
> It's not quite the maximum anymore, is it? More like the minumum
> maximum ;). A better name might better document what the test is
> actually trying to do.
>
> One question I have is whether the unpatched test is still valuable.
> Based on my limited knowledge of the test I suspect it's still a correct
> test of message queues. If so, perhaps renaming the old test (so it's
> not confused with a performance regression) and adding your patched
> version is best?
>

Yes, you're completely right.

I'll resend a patch today.

Regards,
Nadia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LTP] [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
Nadia.Derbey at bull
Feb 21, 2008, 4:36 AM
Post #10 of 26 (1114 views)
Permalink
Matt Helsley wrote:
> On Tue, 2008-02-19 at 18:16 +0100, Nadia Derbey wrote:
>
> <snip>
>
>>+#define MAX_MSGQUEUES 16 /* MSGMNI as defined in linux/msg.h */
>>+
>
>
> It's not quite the maximum anymore, is it? More like the minumum
> maximum ;). A better name might better document what the test is
> actually trying to do.
>
> One question I have is whether the unpatched test is still valuable.
> Based on my limited knowledge of the test I suspect it's still a correct
> test of message queues. If so, perhaps renaming the old test (so it's
> not confused with a performance regression) and adding your patched
> version is best?
>

So, here's the new patch based on Matt's points.

Subrata, it has to be applied on top of the original ltp-full-20080131.
Please tell me if you'd prefer one based on the merged version you've
got (i.e. with my Tuesday patch applied).

Regards,
Nadia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LTP] [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
Nadia.Derbey at bull
Feb 21, 2008, 5:02 AM
Post #11 of 26 (1114 views)
Permalink
Nadia Derbey wrote:
> Matt Helsley wrote:
>
>> On Tue, 2008-02-19 at 18:16 +0100, Nadia Derbey wrote:
>>
>> <snip>
>>
>>> +#define MAX_MSGQUEUES 16 /* MSGMNI as defined in linux/msg.h */
>>> +
>>
>>
>>
>> It's not quite the maximum anymore, is it? More like the minumum
>> maximum ;). A better name might better document what the test is
>> actually trying to do.
>>
>> One question I have is whether the unpatched test is still valuable.
>> Based on my limited knowledge of the test I suspect it's still a correct
>> test of message queues. If so, perhaps renaming the old test (so it's
>> not confused with a performance regression) and adding your patched
>> version is best?
>>
>
> So, here's the new patch based on Matt's points.
>
> Subrata, it has to be applied on top of the original ltp-full-20080131.
> Please tell me if you'd prefer one based on the merged version you've
> got (i.e. with my Tuesday patch applied).
>

Forgot the patch, sorry for that (thx Andrew).

Regards,
Nadia

Attached Files:

Re: [LTP] [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
subrata at linux
Feb 21, 2008, 5:39 AM
Post #12 of 26 (1115 views)
Permalink
> Nadia Derbey wrote:
> > Matt Helsley wrote:
> >
> >> On Tue, 2008-02-19 at 18:16 +0100, Nadia Derbey wrote:
> >>
> >> <snip>
> >>
> >>> +#define MAX_MSGQUEUES 16 /* MSGMNI as defined in linux/msg.h */
> >>> +
> >>
> >>
> >>
> >> It's not quite the maximum anymore, is it? More like the minumum
> >> maximum ;). A better name might better document what the test is
> >> actually trying to do.
> >>
> >> One question I have is whether the unpatched test is still valuable.
> >> Based on my limited knowledge of the test I suspect it's still a correct
> >> test of message queues. If so, perhaps renaming the old test (so it's
> >> not confused with a performance regression) and adding your patched
> >> version is best?
> >>
> >
> > So, here's the new patch based on Matt's points.
> >
> > Subrata, it has to be applied on top of the original ltp-full-20080131.
> > Please tell me if you'd prefer one based on the merged version you've
> > got (i.e. with my Tuesday patch applied).

Nadia, I would prefer Patch on the top of the already merged version (on
top of latest CVS snapshot as of today). Anyways, thanks for all these
effort :-)

--Subrata

> >
>
> Forgot the patch, sorry for that (thx Andrew).
>
> Regards,
> Nadia
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LTP] [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
Nadia.Derbey at bull
Feb 21, 2008, 10:25 PM
Post #13 of 26 (1105 views)
Permalink
Subrata Modak wrote:
>>Nadia Derbey wrote:
>>
>>>Matt Helsley wrote:
>>>
>>>
>>>>On Tue, 2008-02-19 at 18:16 +0100, Nadia Derbey wrote:
>>>>
>>>><snip>
>>>>
>>>>>+#define MAX_MSGQUEUES 16 /* MSGMNI as defined in linux/msg.h */
>>>>>+
>>>>
>>>>
>>>>
>>>>It's not quite the maximum anymore, is it? More like the minumum
>>>>maximum ;). A better name might better document what the test is
>>>>actually trying to do.
>>>>
>>>>One question I have is whether the unpatched test is still valuable.
>>>>Based on my limited knowledge of the test I suspect it's still a correct
>>>>test of message queues. If so, perhaps renaming the old test (so it's
>>>>not confused with a performance regression) and adding your patched
>>>>version is best?
>>>>
>>>
>>>So, here's the new patch based on Matt's points.
>>>
>>>Subrata, it has to be applied on top of the original ltp-full-20080131.
>>>Please tell me if you'd prefer one based on the merged version you've
>>>got (i.e. with my Tuesday patch applied).
>
>
> Nadia, I would prefer Patch on the top of the already merged version (on
> top of latest CVS snapshot as of today). Anyways, thanks for all these
> effort :-)
>
> --Subrata
>

In attachment, you'll find a patch to apply on top of the patches I sent
you on Tuesday.

Regards,
Nadia

Attached Files:

Re: [LTP] [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
subrata at linux
Feb 22, 2008, 12:41 AM
Post #14 of 26 (1104 views)
Permalink
On Fri, 2008-02-22 at 07:25 +0100, Nadia Derbey wrote:
> Subrata Modak wrote:
> >>Nadia Derbey wrote:
> >>
> >>>Matt Helsley wrote:
> >>>
> >>>
> >>>>On Tue, 2008-02-19 at 18:16 +0100, Nadia Derbey wrote:
> >>>>
> >>>><snip>
> >>>>
> >>>>>+#define MAX_MSGQUEUES 16 /* MSGMNI as defined in linux/msg.h */
> >>>>>+
> >>>>
> >>>>
> >>>>
> >>>>It's not quite the maximum anymore, is it? More like the minumum
> >>>>maximum ;). A better name might better document what the test is
> >>>>actually trying to do.
> >>>>
> >>>>One question I have is whether the unpatched test is still valuable.
> >>>>Based on my limited knowledge of the test I suspect it's still a correct
> >>>>test of message queues. If so, perhaps renaming the old test (so it's
> >>>>not confused with a performance regression) and adding your patched
> >>>>version is best?
> >>>>
> >>>
> >>>So, here's the new patch based on Matt's points.
> >>>
> >>>Subrata, it has to be applied on top of the original ltp-full-20080131.
> >>>Please tell me if you'd prefer one based on the merged version you've
> >>>got (i.e. with my Tuesday patch applied).
> >
> >
> > Nadia, I would prefer Patch on the top of the already merged version (on
> > top of latest CVS snapshot as of today). Anyways, thanks for all these
> > effort :-)
> >
> > --Subrata
> >
>
> In attachment, you'll find a patch to apply on top of the patches I sent
> you on Tuesday.

Nadia,

Thanks a ton for that. The same has been merged.

Regards--
Subrata

>
> Regards,
> Nadia

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
tony.luck at intel
Apr 29, 2008, 1:28 PM
Post #15 of 26 (993 views)
Permalink
On Mon, Feb 11, 2008 at 7:16 AM, <Nadia.Derbey@bull.net> wrote:
> Index: linux-2.6.24-mm1/ipc/msg.c
> ===================================================================
> --- linux-2.6.24-mm1.orig/ipc/msg.c 2008-02-07 15:02:29.000000000 +0100
> +++ linux-2.6.24-mm1/ipc/msg.c 2008-02-07 15:24:19.000000000 +0100
...
> +out_callback:
> +
> + printk(KERN_INFO "msgmni has been set to %d for ipc namespace %p\n",
> + ns->msg_ctlmni, ns);
> +}

This patch has now made its way to mainline. I can see how this printk
was really useful to you while developing this patch. But does it add
much value in a production system? It just looks like another piece of
clutter on the console to my uncontainerized eyes.

-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
Nadia.Derbey at bull
May 5, 2008, 1:45 AM
Post #16 of 26 (989 views)
Permalink
Tony Luck wrote:
> On Mon, Feb 11, 2008 at 7:16 AM, <Nadia.Derbey@bull.net> wrote:
>
>> Index: linux-2.6.24-mm1/ipc/msg.c
>> ===================================================================
>> --- linux-2.6.24-mm1.orig/ipc/msg.c 2008-02-07 15:02:29.000000000 +0100
>> +++ linux-2.6.24-mm1/ipc/msg.c 2008-02-07 15:24:19.000000000 +0100
>
> ...
>
>> +out_callback:
>> +
>> + printk(KERN_INFO "msgmni has been set to %d for ipc namespace %p\n",
>> + ns->msg_ctlmni, ns);
>> +}
>
>
> This patch has now made its way to mainline. I can see how this printk
> was really useful to you while developing this patch. But does it add
> much value in a production system? It just looks like another piece of
> clutter on the console to my uncontainerized eyes.
>
> -Tony
>
>


Well, this printk had been suggested by somebody (sorry I don't remember
who) when I first submitted the patch. Actually I think it might be
useful for a sysadmin to be aware of a change in the msgmni value: we
have the message not only at boot time, but also each time msgmni is
recomputed because of a change in the amount of memory.
Also, at boot time, I think it's interesting to have the actual msgmni
value: it used to unconditionally be set to 16. Some applications that
used to need an initialization script setting msgmni to a higher value
might not need that script anymore, since the new value might fit their
needs.

Regards,
Nadia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
tony.luck at intel
May 6, 2008, 9:42 AM
Post #17 of 26 (983 views)
Permalink
> Well, this printk had been suggested by somebody (sorry I don't remember
> who) when I first submitted the patch. Actually I think it might be
> useful for a sysadmin to be aware of a change in the msgmni value: we
> have the message not only at boot time, but also each time msgmni is
> recomputed because of a change in the amount of memory.

If the message is directed at the system administrator, then it would
be nice if there were some more meaningful way to show the namespace
that is affected than just printing the hex address of the kernel structure.

As the sysadmin for my test systems, printing the hex address is mildly
annoying ... I now have to add a new case to my scripts that look at
dmesg output for unusual activity.

Is there some better "name for a namespace" than the address? Perhaps
the process id of the process that instantiated the namespace???

-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
serue at us
May 6, 2008, 11:05 AM
Post #18 of 26 (982 views)
Permalink
Quoting Luck, Tony (tony.luck@intel.com):
> > Well, this printk had been suggested by somebody (sorry I don't remember
> > who) when I first submitted the patch. Actually I think it might be
> > useful for a sysadmin to be aware of a change in the msgmni value: we
> > have the message not only at boot time, but also each time msgmni is
> > recomputed because of a change in the amount of memory.
>
> If the message is directed at the system administrator, then it would
> be nice if there were some more meaningful way to show the namespace
> that is affected than just printing the hex address of the kernel structure.
>
> As the sysadmin for my test systems, printing the hex address is mildly
> annoying ... I now have to add a new case to my scripts that look at
> dmesg output for unusual activity.
>
> Is there some better "name for a namespace" than the address? Perhaps
> the process id of the process that instantiated the namespace???

I agree with Tony here. Aside from the nuisance it is to see that
message on console every time I unshare a namespace, a printk doesn't
seem like the right way to output the info. At most I'd say an audit
message.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
Nadia.Derbey at bull
May 6, 2008, 10:13 PM
Post #19 of 26 (978 views)
Permalink
Luck, Tony wrote:
>>Well, this printk had been suggested by somebody (sorry I don't remember
>>who) when I first submitted the patch. Actually I think it might be
>>useful for a sysadmin to be aware of a change in the msgmni value: we
>>have the message not only at boot time, but also each time msgmni is
>>recomputed because of a change in the amount of memory.
>
>
> If the message is directed at the system administrator, then it would
> be nice if there were some more meaningful way to show the namespace
> that is affected than just printing the hex address of the kernel structure.
>
> As the sysadmin for my test systems, printing the hex address is mildly
> annoying ... I now have to add a new case to my scripts that look at
> dmesg output for unusual activity.
>
> Is there some better "name for a namespace" than the address? Perhaps
> the process id of the process that instantiated the namespace???
>

Unfortunately no when we are inside an ipc namespace, we don't have such
interesting informations. But I agree with you, an address is not
readable enough. I'll try to find a solution.

Regards,
Nadia

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
Nadia.Derbey at bull
May 6, 2008, 10:37 PM
Post #20 of 26 (975 views)
Permalink
Serge E. Hallyn wrote:
> Quoting Luck, Tony (tony.luck@intel.com):
>
>>>Well, this printk had been suggested by somebody (sorry I don't remember
>>>who) when I first submitted the patch. Actually I think it might be
>>>useful for a sysadmin to be aware of a change in the msgmni value: we
>>>have the message not only at boot time, but also each time msgmni is
>>>recomputed because of a change in the amount of memory.
>>
>>If the message is directed at the system administrator, then it would
>>be nice if there were some more meaningful way to show the namespace
>>that is affected than just printing the hex address of the kernel structure.
>>
>>As the sysadmin for my test systems, printing the hex address is mildly
>>annoying ... I now have to add a new case to my scripts that look at
>>dmesg output for unusual activity.
>>
>>Is there some better "name for a namespace" than the address? Perhaps
>>the process id of the process that instantiated the namespace???
>
>
> I agree with Tony here. Aside from the nuisance it is to see that
> message on console every time I unshare a namespace, a printk doesn't
> seem like the right way to output the info.

But you agree that this is happening only because you're doing tests
related to namespaces, right?
I don't think that in a "standard" configuration this will happen very
frequently, but may be I'm wrong.

> At most I'd say an audit
> message.
>

That's a good idea. Thanks, Serge. I'll do that.

Regards,
Nadia

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
serue at us
May 7, 2008, 6:17 AM
Post #21 of 26 (977 views)
Permalink
Quoting Nadia Derbey (Nadia.Derbey@bull.net):
> Serge E. Hallyn wrote:
>> Quoting Luck, Tony (tony.luck@intel.com):
>>>> Well, this printk had been suggested by somebody (sorry I don't remember
>>>> who) when I first submitted the patch. Actually I think it might be
>>>> useful for a sysadmin to be aware of a change in the msgmni value: we
>>>> have the message not only at boot time, but also each time msgmni is
>>>> recomputed because of a change in the amount of memory.
>>>
>>> If the message is directed at the system administrator, then it would
>>> be nice if there were some more meaningful way to show the namespace
>>> that is affected than just printing the hex address of the kernel
>>> structure.
>>>
>>> As the sysadmin for my test systems, printing the hex address is mildly
>>> annoying ... I now have to add a new case to my scripts that look at
>>> dmesg output for unusual activity.
>>>
>>> Is there some better "name for a namespace" than the address? Perhaps
>>> the process id of the process that instantiated the namespace???
>> I agree with Tony here. Aside from the nuisance it is to see that
>> message on console every time I unshare a namespace, a printk doesn't
>> seem like the right way to output the info.
>
> But you agree that this is happening only because you're doing tests
> related to namespaces, right?

Yup :)

> I don't think that in a "standard" configuration this will happen very
> frequently, but may be I'm wrong.
>
>> At most I'd say an audit
>> message.
>
> That's a good idea. Thanks, Serge. I'll do that.

It'll probably still end up a printk for me, but it'll be my own fault
for not setting up audit.

> Regards,
> Nadia

thanks,
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
matthltc at us
May 7, 2008, 11:12 AM
Post #22 of 26 (977 views)
Permalink
On Wed, 2008-05-07 at 08:17 -0500, Serge E. Hallyn wrote:
> Quoting Nadia Derbey (Nadia.Derbey@bull.net):
> > Serge E. Hallyn wrote:
> >> Quoting Luck, Tony (tony.luck@intel.com):
> >>>> Well, this printk had been suggested by somebody (sorry I don't remember
> >>>> who) when I first submitted the patch. Actually I think it might be
> >>>> useful for a sysadmin to be aware of a change in the msgmni value: we
> >>>> have the message not only at boot time, but also each time msgmni is
> >>>> recomputed because of a change in the amount of memory.
> >>>
> >>> If the message is directed at the system administrator, then it would
> >>> be nice if there were some more meaningful way to show the namespace
> >>> that is affected than just printing the hex address of the kernel
> >>> structure.
> >>>
> >>> As the sysadmin for my test systems, printing the hex address is mildly
> >>> annoying ... I now have to add a new case to my scripts that look at
> >>> dmesg output for unusual activity.
> >>>
> >>> Is there some better "name for a namespace" than the address? Perhaps
> >>> the process id of the process that instantiated the namespace???
> >> I agree with Tony here. Aside from the nuisance it is to see that
> >> message on console every time I unshare a namespace, a printk doesn't
> >> seem like the right way to output the info.
> >
> > But you agree that this is happening only because you're doing tests
> > related to namespaces, right?
>
> Yup :)
>
> > I don't think that in a "standard" configuration this will happen very
> > frequently, but may be I'm wrong.
> >
> >> At most I'd say an audit
> >> message.
>
> > That's a good idea. Thanks, Serge. I'll do that.

I'm not familiar with kernel policies regarding audit messages. Are
audit messages treated anything like kernel interfaces when it comes to
removing/changing them?

Cheers,
-Matt Helsley

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
mtk.manpages at googlemail
May 20, 2008, 7:28 AM
Post #23 of 26 (959 views)
Permalink
Hello Nadia,

Regarding your:

[PATCH 1/8] Scaling msgmni to the amount of lowmem
http://article.gmane.org/gmane.linux.kernel/637849/
which I see has made its way in 2.6.26-rc

Your patch has the following change:

-#define MSGPOOL (MSGMNI*MSGMNB/1024) /* size in kilobytes of message pool */
+#define MSGPOOL (MSGMNI * MSGMNB) /* size in bytes of message pool */

Since this constitutes a kernel-userland interface change, so please
do CC me, so that I can change the man pages if needed.

The man page (http://www.kernel.org/doc/man-pages/online/pages/man2/msgctl.2.html)
does indeed say that msgpool is "unused". But that meant "unused by
the kernel" (sorry -- I probably should have worded that text better).
And, as you spotted, the page also wrongly said the value is in
bytes.

However, making this change affects the ABI. A userspace application
that was previously using msgctl(IPC_INFO) to retrieve the msgpool
field will be affected by the factor-of-1024 change. I strongly
suspect that there no such applications, or certainly none that care
(since this value is unused by the kernel). But was there a reason
for making this change, aside from the fact that the code and the man
page didn't agree?

Cheers,

Michael

--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
Nadia.Derbey at bull
May 20, 2008, 7:45 AM
Post #24 of 26 (958 views)
Permalink
Michael Kerrisk wrote:
> Hello Nadia,
>
> Regarding your:
>
> [PATCH 1/8] Scaling msgmni to the amount of lowmem
> http://article.gmane.org/gmane.linux.kernel/637849/
> which I see has made its way in 2.6.26-rc
>
> Your patch has the following change:
>
> -#define MSGPOOL (MSGMNI*MSGMNB/1024) /* size in kilobytes of message pool */
> +#define MSGPOOL (MSGMNI * MSGMNB) /* size in bytes of message pool */
>
> Since this constitutes a kernel-userland interface change, so please
> do CC me, so that I can change the man pages if needed.

Oops, sorry for not doing it: I misunderstood the "unused"

>
> The man page (http://www.kernel.org/doc/man-pages/online/pages/man2/msgctl.2.html)
> does indeed say that msgpool is "unused". But that meant "unused by
> the kernel" (sorry -- I probably should have worded that text better).
> And, as you spotted, the page also wrongly said the value is in
> bytes.
>
> However, making this change affects the ABI. A userspace application
> that was previously using msgctl(IPC_INFO) to retrieve the msgpool
> field will be affected by the factor-of-1024 change. I strongly
> suspect that there no such applications, or certainly none that care
> (since this value is unused by the kernel). But was there a reason
> for making this change, aside from the fact that the code and the man
> page didn't agree?
>

No, that was the only reason.
Should I repost a patch to set it back as it used to be?

Regards
Nadia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] Scaling msgmni to the amount of lowmem [ In reply to ]
mtk.manpages at googlemail
May 20, 2008, 7:56 AM
Post #25 of 26 (959 views)
Permalink
[.Fixing the bad list address in my initial mail: CC += linux-mm@kvack.org]

On Tue, May 20, 2008 at 4:45 PM, Nadia Derbey <Nadia.Derbey@bull.net> wrote:
> Michael Kerrisk wrote:
>>
>> Hello Nadia,
>>
>> Regarding your:
>>
>> [PATCH 1/8] Scaling msgmni to the amount of lowmem
>> http://article.gmane.org/gmane.linux.kernel/637849/
>> which I see has made its way in 2.6.26-rc
>>
>> Your patch has the following change:
>>
>> -#define MSGPOOL (MSGMNI*MSGMNB/1024) /* size in kilobytes of message
>> pool */
>> +#define MSGPOOL (MSGMNI * MSGMNB) /* size in bytes of message pool */
>>
>> Since this constitutes a kernel-userland interface change, so please
>> do CC me, so that I can change the man pages if needed.
>
> Oops, sorry for not doing it: I misunderstood the "unused"
>
>>
>> The man page
>> (http://www.kernel.org/doc/man-pages/online/pages/man2/msgctl.2.html)
>> does indeed say that msgpool is "unused". But that meant "unused by
>> the kernel" (sorry -- I probably should have worded that text better).
>> And, as you spotted, the page also wrongly said the value is in
>> bytes.
>>
>> However, making this change affects the ABI. A userspace application
>> that was previously using msgctl(IPC_INFO) to retrieve the msgpool
>> field will be affected by the factor-of-1024 change. I strongly
>> suspect that there no such applications, or certainly none that care
>> (since this value is unused by the kernel). But was there a reason
>> for making this change, aside from the fact that the code and the man
>> page didn't agree?
>>
>
> No, that was the only reason.
> Should I repost a patch to set it back as it used to be?

On the one hand, I'd be inclined to leave things as they were pre
2.6.26. On the other hand, I believe that on other systems that have
the limit, msgpool is a limit in bytes. (But documentation of these
details on other systems is very thin on the ground.) I wonder if
anyone else has some knowledge here?


--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
1 2  View All

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal