Re: [LTP] [PATCH 1/8] Scaling msgmni to the amount of lowmem
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: > > > > >+#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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
Subrata Modak wrote:
Nadia Derbey wrote:
Matt Helsley wrote:
On Tue, 2008-02-19 at 18:16 +0100, Nadia Derbey wrote:
+#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
Since msgmni now scales to the memory size, it may reach big values.
To avoid forking 2*msgmni processes and create msgmni msg queues, take the min
between the procfs value and MSGMNI (as found in linux/msg.h).
Also integrated the following in libipc.a:
. get_max_msgqueues()
. get_used_msgqueues()
Signed-off-by: Nadia Derbey <[EMAIL PROTECTED]>
---
testcases/kernel/syscalls/ipc/lib/ipcmsg.h |7
testcases/kernel/syscalls/ipc/lib/libipc.c | 54 +
testcases/kernel/syscalls/ipc/msgctl/msgctl08.c | 42 -
testcases/kernel/syscalls/ipc/msgctl/msgctl09.c | 42 -
testcases/kernel/syscalls/ipc/msgctl/msgctl10.c | 527 ++
testcases/kernel/syscalls/ipc/msgctl/msgctl11.c | 696
testcases/kernel/syscalls/ipc/msgget/Makefile |3
testcases/kernel/syscalls/ipc/msgget/msgget03.c | 22
8 files changed, 1318 insertions(+), 75 deletions(-)
Index: ltp-full-20080131/testcases/kernel/syscalls/ipc/lib/libipc.c
===
--- ltp-full-20080131.orig/testcases/kernel/syscalls/ipc/lib/libipc.c 2008-02-22 07:57:47.0 +0100
+++ ltp-full-20080131/testcases/kernel/syscalls/ipc/lib/libipc.c 2008-02-22 08:02:55.0 +0100
@@ -201,3 +201,57 @@ rm_shm(int shm_id)
tst_resm(TINFO, "id = %d", shm_id);
}
}
+
+#define BUFSIZE 512
+
+/*
+ * Get the number of message queues already in use
+ */
+int
+get_used_msgqueues()
+{
+ FILE *f;
+ int used_queues;
+ char buff[BUFSIZE];
+
+ f = popen("ipcs -q", "r");
+ if (!f) {
+ tst_resm(TBROK, "Could not run 'ipcs' to calculate used "
+ "message queues");
+ tst_exit();
+ }
+ /* FIXME: Start at -4 because ipcs prints four lines of header */
+ for (used_queues = -4; fgets(buff, BUFSIZE, f); used_queues++)
+ ;
+ pclose(f);
+ if (used_queues < 0) {
+ tst_resm(TBROK, "Could not read output of 'ipcs' to "
+ "calculate used message queues");
+ tst_exit();
+ }
+ return used_queues;
+}
+
+/*
+ * Get the max number of message queues allowed on system
+ */
+int
+get_max_msgqueues()
+{
+ FILE *f;
+ char buff[BUFSIZE];
+
+ /* Get the max number of message queues allowed on system */
+ f = fopen("/proc/sys/kernel/msgmni", "r");
+ if (!f) {
+ tst_resm(TBROK, "Could not open /proc/sys/kernel/msgmni");
+ return -1;
+ }
+ if (!fgets(buff, BUFSIZE, f)) {
+ fclose(f);
+ tst_resm(TBROK, "Could not read /proc/sys/kernel/msgmni");
+ return -1;
+ }
+ fclose(f);
+ return atoi(buff);
+}
Index: ltp-full-20080131/testcases/kernel/syscalls/ipc/lib/ipcmsg.h
===
--- ltp-full-20080131.orig/testcases/kernel/syscalls/ipc/lib/ipcmsg.h 2008-02-22 07:57:47.0 +0100
+++ ltp-full-20080131/testcases/kernel/syscalls/ipc/lib/ipcmsg.h 2008-02-22 08:04:15.0 +0100
@@ -41,7 +41,9 @@ void setup(void);
#define MSGSIZE 1024 /* a resonable size for a message */
#define MSGTYPE 1 /* a type ID for a message */
-#define MAX_MSGQUEUES 16 /* MSGMNI as defined in linux/msg.h */
+#define NR_MSGQUEUES 16 /* MSGMNI as defined in linux/msg.h */
+
+#define min(a, b) (((a) < (b)) ? (a) : (b))
typedef struct mbuf { /* a generic message structure */
long mtype;
@@ -61,4 +63,7 @@ void rm_queue(int);
int getipckey();
int getuserid(char *);
+int get_max_msgqueues(void);
+int get_used_msgqueues(void);
+
#endif /* ipcmsg.h */
Index: ltp-full-20080131/testcases/kernel/syscalls/ipc/msgctl/msgctl10.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ ltp-full-20080131/testcases/kernel/syscalls/ipc/msgctl/msgctl10.c 2008-02-22 08:05:53.0 +0100
@@ -0,0 +1,527 @@
+/*
+ *
+ * Copyright (c) International Business Machines Corp., 2002
+ *
+ * This program is free software; you can
Re: [LTP] [PATCH 1/8] Scaling msgmni to the amount of lowmem
> Nadia Derbey wrote: > > Matt Helsley wrote: > > > >> On Tue, 2008-02-19 at 18:16 +0100, Nadia Derbey wrote: > >> > >> > >> > >>> +#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 [EMAIL PROTECTED] 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
Nadia Derbey wrote:
Matt Helsley wrote:
On Tue, 2008-02-19 at 18:16 +0100, Nadia Derbey wrote:
+#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
Since msgmni now scales to the memory size, it may reach big values.
To avoid forking 2*msgmni processes and create msgmni msg queues, take the min
between the procfs value and MSGMNI (as found in linux/msg.h).
Also fixed the Makefiles in ipc/lib and ipc/msgctl: there was no dependency
on the lib/ipc*.h header files.
Also integrated the following in libipc.a:
. get_max_msgqueues()
. get_used_msgqueues()
Signed-off-by: Nadia Derbey <[EMAIL PROTECTED]>
---
testcases/kernel/syscalls/ipc/lib/Makefile |3
testcases/kernel/syscalls/ipc/lib/ipcmsg.h |7
testcases/kernel/syscalls/ipc/lib/libipc.c | 54 +
testcases/kernel/syscalls/ipc/msgctl/Makefile |3
testcases/kernel/syscalls/ipc/msgctl/msgctl08.c | 63 --
testcases/kernel/syscalls/ipc/msgctl/msgctl09.c | 62 --
testcases/kernel/syscalls/ipc/msgctl/msgctl10.c | 527 ++
testcases/kernel/syscalls/ipc/msgctl/msgctl11.c | 696
testcases/kernel/syscalls/ipc/msgget/Makefile |3
testcases/kernel/syscalls/ipc/msgget/msgget03.c | 22
10 files changed, 1326 insertions(+), 114 deletions(-)
Index: ltp-full-20080131/testcases/kernel/syscalls/ipc/lib/ipcmsg.h
===
--- ltp-full-20080131.orig/testcases/kernel/syscalls/ipc/lib/ipcmsg.h 2008-02-21 10:45:36.0 +0100
+++ ltp-full-20080131/testcases/kernel/syscalls/ipc/lib/ipcmsg.h 2008-02-21 14:09:00.0 +0100
@@ -41,6 +41,10 @@ void setup(void);
#define MSGSIZE 1024 /* a resonable size for a message */
#define MSGTYPE 1 /* a type ID for a message */
+#define NR_MSGQUEUES 16 /* MSGMNI as defined in linux/msg.h */
+
+#define min(a, b) (((a) < (b)) ? (a) : (b))
+
typedef struct mbuf { /* a generic message structure */
long mtype;
char mtext[MSGSIZE + 1]; /* add 1 here so the message can be 1024 */
@@ -59,4 +63,7 @@ void rm_queue(int);
int getipckey();
int getuserid(char *);
+int get_max_msgqueues(void);
+int get_used_msgqueues(void);
+
#endif /* ipcmsg.h */
Index: ltp-full-20080131/testcases/kernel/syscalls/ipc/lib/libipc.c
===
--- ltp-full-20080131.orig/testcases/kernel/syscalls/ipc/lib/libipc.c 2008-02-21 10:45:36.0 +0100
+++ ltp-full-20080131/testcases/kernel/syscalls/ipc/lib/libipc.c 2008-02-21 13:35:41.0 +0100
@@ -201,3 +201,57 @@ rm_shm(int shm_id)
tst_resm(TINFO, "id = %d", shm_id);
}
}
+
+#define BUFSIZE 512
+
+/*
+ * Get the number of message queues already in use
+ */
+int
+get_used_msgqueues()
+{
+ FILE *f;
+ int used_queues;
+ char buff[BUFSIZE];
+
+ f = popen("ipcs -q", "r");
+ if (!f) {
+ tst_resm(TBROK, "Could not run 'ipcs' to calculate used "
+ "message queues");
+ tst_exit();
+ }
+ /* FIXME: Start at -4 because ipcs prints four lines of header */
+ for (used_queues = -4; fgets(buff, BUFSIZE, f); used_queues++)
+ ;
+ pclose(f);
+ if (used_queues < 0) {
+ tst_resm(TBROK, "Could not read output of 'ipcs' to "
+ "calculate used message queues");
+ tst_exit();
+ }
+ return used_queues;
+}
+
+/*
+ * Get the max number of message queues allowed on system
+ */
+int
+get_max_msgqueues()
+{
+ FILE *f;
+ char buff[BUFSIZE];
+
+ /* Get the max number of message queues allowed on system */
+ f = fopen("/proc/sys/kernel/msgmni", "r");
+ if (!f) {
+ tst_resm(TBROK, "Could not open /proc/sys/kernel/msgmni");
+ return -1;
+ }
+ if (!fgets(buff, BUFSIZE, f)) {
+ fclose(f);
+ tst_resm(TBROK, "Could not read /proc/sys/kernel/msgmni");
+ return -1;
+ }
+ fclose(f);
+ return atoi(buff);
+}
Index: ltp-full-20080131/testcases/kernel/syscalls/ipc/msgctl/msgctl08.c
===
--- ltp-full-20080131.orig/testcases/kernel/syscalls/ipc/msgctl/msgctl08.c 2008-02-21 10:45:36.0 +0100
+++ ltp-full-20080131/testcases/kernel/syscalls/ipc/msgctl/msgctl08.c 2008-02-21 14:18:23.0 +0100
@@ -50,6 +50,7 @@
#include
#include "test.h"
#include "usctest.h"
+#include
Re: [LTP] [PATCH 1/8] Scaling msgmni to the amount of lowmem
Matt Helsley wrote: On Tue, 2008-02-19 at 18:16 +0100, Nadia Derbey wrote: +#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 [EMAIL PROTECTED] 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
Matt Helsley wrote: On Tue, 2008-02-19 at 18:16 +0100, Nadia Derbey wrote: +#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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
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
Since msgmni now scales to the memory size, it may reach big values.
To avoid forking 2*msgmni processes and create msgmni msg queues, take the min
between the procfs value and MSGMNI (as found in linux/msg.h).
Also fixed the Makefiles in ipc/lib and ipc/msgctl: there was no dependency
on the lib/ipc*.h header files.
Also integrated the following in libipc.a:
. get_max_msgqueues()
. get_used_msgqueues()
Signed-off-by: Nadia Derbey [EMAIL PROTECTED]
---
testcases/kernel/syscalls/ipc/lib/Makefile |3
testcases/kernel/syscalls/ipc/lib/ipcmsg.h |7
testcases/kernel/syscalls/ipc/lib/libipc.c | 54 +
testcases/kernel/syscalls/ipc/msgctl/Makefile |3
testcases/kernel/syscalls/ipc/msgctl/msgctl08.c | 63 --
testcases/kernel/syscalls/ipc/msgctl/msgctl09.c | 62 --
testcases/kernel/syscalls/ipc/msgctl/msgctl10.c | 527 ++
testcases/kernel/syscalls/ipc/msgctl/msgctl11.c | 696
testcases/kernel/syscalls/ipc/msgget/Makefile |3
testcases/kernel/syscalls/ipc/msgget/msgget03.c | 22
10 files changed, 1326 insertions(+), 114 deletions(-)
Index: ltp-full-20080131/testcases/kernel/syscalls/ipc/lib/ipcmsg.h
===
--- ltp-full-20080131.orig/testcases/kernel/syscalls/ipc/lib/ipcmsg.h 2008-02-21 10:45:36.0 +0100
+++ ltp-full-20080131/testcases/kernel/syscalls/ipc/lib/ipcmsg.h 2008-02-21 14:09:00.0 +0100
@@ -41,6 +41,10 @@ void setup(void);
#define MSGSIZE 1024 /* a resonable size for a message */
#define MSGTYPE 1 /* a type ID for a message */
+#define NR_MSGQUEUES 16 /* MSGMNI as defined in linux/msg.h */
+
+#define min(a, b) (((a) (b)) ? (a) : (b))
+
typedef struct mbuf { /* a generic message structure */
long mtype;
char mtext[MSGSIZE + 1]; /* add 1 here so the message can be 1024 */
@@ -59,4 +63,7 @@ void rm_queue(int);
int getipckey();
int getuserid(char *);
+int get_max_msgqueues(void);
+int get_used_msgqueues(void);
+
#endif /* ipcmsg.h */
Index: ltp-full-20080131/testcases/kernel/syscalls/ipc/lib/libipc.c
===
--- ltp-full-20080131.orig/testcases/kernel/syscalls/ipc/lib/libipc.c 2008-02-21 10:45:36.0 +0100
+++ ltp-full-20080131/testcases/kernel/syscalls/ipc/lib/libipc.c 2008-02-21 13:35:41.0 +0100
@@ -201,3 +201,57 @@ rm_shm(int shm_id)
tst_resm(TINFO, id = %d, shm_id);
}
}
+
+#define BUFSIZE 512
+
+/*
+ * Get the number of message queues already in use
+ */
+int
+get_used_msgqueues()
+{
+ FILE *f;
+ int used_queues;
+ char buff[BUFSIZE];
+
+ f = popen(ipcs -q, r);
+ if (!f) {
+ tst_resm(TBROK, Could not run 'ipcs' to calculate used
+ message queues);
+ tst_exit();
+ }
+ /* FIXME: Start at -4 because ipcs prints four lines of header */
+ for (used_queues = -4; fgets(buff, BUFSIZE, f); used_queues++)
+ ;
+ pclose(f);
+ if (used_queues 0) {
+ tst_resm(TBROK, Could not read output of 'ipcs' to
+ calculate used message queues);
+ tst_exit();
+ }
+ return used_queues;
+}
+
+/*
+ * Get the max number of message queues allowed on system
+ */
+int
+get_max_msgqueues()
+{
+ FILE *f;
+ char buff[BUFSIZE];
+
+ /* Get the max number of message queues allowed on system */
+ f = fopen(/proc/sys/kernel/msgmni, r);
+ if (!f) {
+ tst_resm(TBROK, Could not open /proc/sys/kernel/msgmni);
+ return -1;
+ }
+ if (!fgets(buff, BUFSIZE, f)) {
+ fclose(f);
+ tst_resm(TBROK, Could not read /proc/sys/kernel/msgmni);
+ return -1;
+ }
+ fclose(f);
+ return atoi(buff);
+}
Index: ltp-full-20080131/testcases/kernel/syscalls/ipc/msgctl/msgctl08.c
===
--- ltp-full-20080131.orig/testcases/kernel/syscalls/ipc/msgctl/msgctl08.c 2008-02-21 10:45:36.0 +0100
+++ ltp-full-20080131/testcases/kernel/syscalls/ipc/msgctl/msgctl08.c 2008-02-21 14:18:23.0 +0100
@@ -50,6 +50,7 @@
#include sys/msg.h
#include test.h
#include usctest.h
+#include ipcmsg.h
void
Re: [LTP] [PATCH 1/8] Scaling msgmni to the amount of lowmem
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 [EMAIL PROTECTED] 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
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
Since msgmni now scales to the memory size, it may reach big values.
To avoid forking 2*msgmni processes and create msgmni msg queues, take the min
between the procfs value and MSGMNI (as found in linux/msg.h).
Also integrated the following in libipc.a:
. get_max_msgqueues()
. get_used_msgqueues()
Signed-off-by: Nadia Derbey [EMAIL PROTECTED]
---
testcases/kernel/syscalls/ipc/lib/ipcmsg.h |7
testcases/kernel/syscalls/ipc/lib/libipc.c | 54 +
testcases/kernel/syscalls/ipc/msgctl/msgctl08.c | 42 -
testcases/kernel/syscalls/ipc/msgctl/msgctl09.c | 42 -
testcases/kernel/syscalls/ipc/msgctl/msgctl10.c | 527 ++
testcases/kernel/syscalls/ipc/msgctl/msgctl11.c | 696
testcases/kernel/syscalls/ipc/msgget/Makefile |3
testcases/kernel/syscalls/ipc/msgget/msgget03.c | 22
8 files changed, 1318 insertions(+), 75 deletions(-)
Index: ltp-full-20080131/testcases/kernel/syscalls/ipc/lib/libipc.c
===
--- ltp-full-20080131.orig/testcases/kernel/syscalls/ipc/lib/libipc.c 2008-02-22 07:57:47.0 +0100
+++ ltp-full-20080131/testcases/kernel/syscalls/ipc/lib/libipc.c 2008-02-22 08:02:55.0 +0100
@@ -201,3 +201,57 @@ rm_shm(int shm_id)
tst_resm(TINFO, id = %d, shm_id);
}
}
+
+#define BUFSIZE 512
+
+/*
+ * Get the number of message queues already in use
+ */
+int
+get_used_msgqueues()
+{
+ FILE *f;
+ int used_queues;
+ char buff[BUFSIZE];
+
+ f = popen(ipcs -q, r);
+ if (!f) {
+ tst_resm(TBROK, Could not run 'ipcs' to calculate used
+ message queues);
+ tst_exit();
+ }
+ /* FIXME: Start at -4 because ipcs prints four lines of header */
+ for (used_queues = -4; fgets(buff, BUFSIZE, f); used_queues++)
+ ;
+ pclose(f);
+ if (used_queues 0) {
+ tst_resm(TBROK, Could not read output of 'ipcs' to
+ calculate used message queues);
+ tst_exit();
+ }
+ return used_queues;
+}
+
+/*
+ * Get the max number of message queues allowed on system
+ */
+int
+get_max_msgqueues()
+{
+ FILE *f;
+ char buff[BUFSIZE];
+
+ /* Get the max number of message queues allowed on system */
+ f = fopen(/proc/sys/kernel/msgmni, r);
+ if (!f) {
+ tst_resm(TBROK, Could not open /proc/sys/kernel/msgmni);
+ return -1;
+ }
+ if (!fgets(buff, BUFSIZE, f)) {
+ fclose(f);
+ tst_resm(TBROK, Could not read /proc/sys/kernel/msgmni);
+ return -1;
+ }
+ fclose(f);
+ return atoi(buff);
+}
Index: ltp-full-20080131/testcases/kernel/syscalls/ipc/lib/ipcmsg.h
===
--- ltp-full-20080131.orig/testcases/kernel/syscalls/ipc/lib/ipcmsg.h 2008-02-22 07:57:47.0 +0100
+++ ltp-full-20080131/testcases/kernel/syscalls/ipc/lib/ipcmsg.h 2008-02-22 08:04:15.0 +0100
@@ -41,7 +41,9 @@ void setup(void);
#define MSGSIZE 1024 /* a resonable size for a message */
#define MSGTYPE 1 /* a type ID for a message */
-#define MAX_MSGQUEUES 16 /* MSGMNI as defined in linux/msg.h */
+#define NR_MSGQUEUES 16 /* MSGMNI as defined in linux/msg.h */
+
+#define min(a, b) (((a) (b)) ? (a) : (b))
typedef struct mbuf { /* a generic message structure */
long mtype;
@@ -61,4 +63,7 @@ void rm_queue(int);
int getipckey();
int getuserid(char *);
+int get_max_msgqueues(void);
+int get_used_msgqueues(void);
+
#endif /* ipcmsg.h */
Index: ltp-full-20080131/testcases/kernel/syscalls/ipc/msgctl/msgctl10.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ ltp-full-20080131/testcases/kernel/syscalls/ipc/msgctl/msgctl10.c 2008-02-22 08:05:53.0 +0100
@@ -0,0 +1,527 @@
+/*
+ *
+ * Copyright (c) International Business Machines Corp., 2002
+ *
+ * This program is free software; you can redistribute it and/or modify
Re: [LTP] [PATCH 1/8] Scaling msgmni to the amount of lowmem
> Subrata Modak wrote: > >>Nadia Derbey wrote: > >> > >>>Andrew Morton wrote: > >>> > >>> > On Mon, 11 Feb 2008 15:16:47 +0100 [EMAIL PROTECTED] 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 10 16" it completes fast. > >>> > >>>Doing the follwing on the ref kernel: > >>>echo 1746 > /proc/sys/kernel/msgmni > >>>msgctl08 10 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 10 XXX; date > >> > >> > >>gives us the following results: > >>XXX 16 32 64 128 256 512 1024 1746 > >>time(secs) 248163264132241 > >> > >>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 [EMAIL PROTECTED] 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
Subrata Modak wrote: Nadia Derbey wrote: Andrew Morton wrote: On Mon, 11 Feb 2008 15:16:47 +0100 [EMAIL PROTECTED] 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 10 16 it completes fast. Doing the follwing on the ref kernel: echo 1746 /proc/sys/kernel/msgmni msgctl08 10 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 10 XXX; date gives us the following results: XXX 16 32 64 128 256 512 1024 1746 time(secs) 248163264132241 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 [EMAIL PROTECTED] 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
On Tue, 2008-02-19 at 18:16 +0100, Nadia Derbey wrote: > +#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? Cheers, -Matt Helsley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
Subrata Modak wrote:
Nadia Derbey wrote:
Andrew Morton wrote:
On Mon, 11 Feb 2008 15:16:47 +0100 [EMAIL PROTECTED] 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 10 16" it completes fast.
Doing the follwing on the ref kernel:
echo 1746 > /proc/sys/kernel/msgmni
msgctl08 10 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 10 XXX; date
gives us the following results:
XXX 16 32 64 128 256 512 1024 1746
time(secs) 248163264132241
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
Since msgmni now scales to the memory size, it may reach big values.
To avoid forking 2*msgmni processes and create msgmni msg queues, do not take
msgmni from procfs anymore.
Just define it as 16 (which is the MSGMNI constant value in linux/msg.h)
Also fixed the Makefiles in ipc/lib and ipc/msgctl: there was no dependency
on the lib/ipc*.h header files.
Signed-off-by: Nadia Derbey <[EMAIL PROTECTED]>
---
testcases/kernel/syscalls/ipc/lib/Makefile |3 +++
testcases/kernel/syscalls/ipc/lib/ipcmsg.h |2 ++
testcases/kernel/syscalls/ipc/msgctl/Makefile |3 +++
testcases/kernel/syscalls/ipc/msgctl/msgctl08.c | 23 ++-
testcases/kernel/syscalls/ipc/msgctl/msgctl09.c | 24 ++--
5 files changed, 12 insertions(+), 43 deletions(-)
Index: ltp-full-20080131/testcases/kernel/syscalls/ipc/msgctl/msgctl08.c
===
--- ltp-full-20080131.orig/testcases/kernel/syscalls/ipc/msgctl/msgctl08.c 2006-02-11 05:46:36.0 +0100
+++ ltp-full-20080131/testcases/kernel/syscalls/ipc/msgctl/msgctl08.c 2008-02-19 18:45:27.0 +0100
@@ -50,6 +50,7 @@
#include
#include "test.h"
#include "usctest.h"
+#include "ipcmsg.h"
void setup();
void cleanup();
@@ -479,26 +480,6 @@ static int get_used_msgqueues()
return used_queues;
}
-/** Get the max number of message queues allowed on system */
-static int get_max_msgqueues()
-{
-FILE *f;
-char buff[BUFSIZE];
-
-/* Get the max number of message queues allowed on system */
-f = fopen("/proc/sys/kernel/msgmni", "r");
-if (!f){
-tst_resm(TBROK,"Could not open /proc/sys/kernel/msgmni");
-tst_exit();
-}
-if (!fgets(buff, BUFSIZE, f)) {
-tst_resm(TBROK,"Could not read /proc/sys/kernel/msgmni");
-tst_exit();
-
Re: [LTP] [PATCH 1/8] Scaling msgmni to the amount of lowmem
> Nadia Derbey wrote: > > Andrew Morton wrote: > > > >> On Mon, 11 Feb 2008 15:16:47 +0100 [EMAIL PROTECTED] 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 10 16" it completes fast. > > > > Doing the follwing on the ref kernel: > > echo 1746 > /proc/sys/kernel/msgmni > > msgctl08 10 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 10 XXX; date > > > gives us the following results: > XXX 16 32 64 128 256 512 1024 1746 > time(secs) 248163264132241 > > 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/vse012070mrt/direct/01/ > ___ > Ltp-list mailing list > [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] 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
Nadia Derbey wrote: Andrew Morton wrote: On Mon, 11 Feb 2008 15:16:47 +0100 [EMAIL PROTECTED] 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 10 16 it completes fast. Doing the follwing on the ref kernel: echo 1746 /proc/sys/kernel/msgmni msgctl08 10 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 10 XXX; date gives us the following results: XXX 16 32 64 128 256 512 1024 1746 time(secs) 248163264132241 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/vse012070mrt/direct/01/ ___ Ltp-list mailing list [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Subrata Modak wrote:
Nadia Derbey wrote:
Andrew Morton wrote:
On Mon, 11 Feb 2008 15:16:47 +0100 [EMAIL PROTECTED] 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 10 16 it completes fast.
Doing the follwing on the ref kernel:
echo 1746 /proc/sys/kernel/msgmni
msgctl08 10 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 10 XXX; date
gives us the following results:
XXX 16 32 64 128 256 512 1024 1746
time(secs) 248163264132241
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
Since msgmni now scales to the memory size, it may reach big values.
To avoid forking 2*msgmni processes and create msgmni msg queues, do not take
msgmni from procfs anymore.
Just define it as 16 (which is the MSGMNI constant value in linux/msg.h)
Also fixed the Makefiles in ipc/lib and ipc/msgctl: there was no dependency
on the lib/ipc*.h header files.
Signed-off-by: Nadia Derbey [EMAIL PROTECTED]
---
testcases/kernel/syscalls/ipc/lib/Makefile |3 +++
testcases/kernel/syscalls/ipc/lib/ipcmsg.h |2 ++
testcases/kernel/syscalls/ipc/msgctl/Makefile |3 +++
testcases/kernel/syscalls/ipc/msgctl/msgctl08.c | 23 ++-
testcases/kernel/syscalls/ipc/msgctl/msgctl09.c | 24 ++--
5 files changed, 12 insertions(+), 43 deletions(-)
Index: ltp-full-20080131/testcases/kernel/syscalls/ipc/msgctl/msgctl08.c
===
--- ltp-full-20080131.orig/testcases/kernel/syscalls/ipc/msgctl/msgctl08.c 2006-02-11 05:46:36.0 +0100
+++ ltp-full-20080131/testcases/kernel/syscalls/ipc/msgctl/msgctl08.c 2008-02-19 18:45:27.0 +0100
@@ -50,6 +50,7 @@
#include sys/msg.h
#include test.h
#include usctest.h
+#include ipcmsg.h
void setup();
void cleanup();
@@ -479,26 +480,6 @@ static int get_used_msgqueues()
return used_queues;
}
-/** Get the max number of message queues allowed on system */
-static int get_max_msgqueues()
-{
-FILE *f;
-char buff[BUFSIZE];
-
-/* Get the max number of message queues allowed on system */
-f = fopen(/proc/sys/kernel/msgmni, r);
-if (!f){
-tst_resm(TBROK,Could not open /proc/sys/kernel/msgmni);
-tst_exit();
-}
-if (!fgets(buff, BUFSIZE, f)) {
-tst_resm(TBROK,Could not read /proc/sys/kernel/msgmni);
-tst_exit();
-}
-
Re: [LTP] [PATCH 1/8] Scaling msgmni to the amount of lowmem
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
