Messages in this thread | | | Date | Fri, 08 Jun 2007 12:12:14 +0200 | From | Nadia Derbey <> | Subject | Re: [RFC][PATCH 1/6] Storing ipcs into radix trees |
| |
Ingo Oeser wrote: > Hi Nadia, > > good to see someone is pounding this old beast again :-) > > On Thursday 07 June 2007, Nadia.Derbey@bull.net wrote: > >>Index: linux-2.6.21/ipc/util.h >>=================================================================== >>--- linux-2.6.21.orig/ipc/util.h 2007-06-07 11:00:30.000000000 +0200 >>+++ linux-2.6.21/ipc/util.h 2007-06-07 11:07:22.000000000 +0200 >>@@ -13,6 +13,8 @@ >> #define USHRT_MAX 0xffff >> #define SEQ_MULTIPLIER (IPCMNI) >> >>+#define IPCS_MAX_SCAN_ENTRIES 256 > > > That ... > > >>Index: linux-2.6.21/ipc/util.c >>=================================================================== >>--- linux-2.6.21.orig/ipc/util.c 2007-06-07 11:00:30.000000000 +0200 >>+++ linux-2.6.21/ipc/util.c 2007-06-07 11:29:43.000000000 +0200 >>@@ -252,72 +241,94 @@ void __init ipc_init_proc_interface(cons >> * @key: The key to find >> * >> * Requires ipc_ids.mutex locked. >>- * Returns the identifier if found or -1 if not. >>+ * Returns the LOCKED pointer to the ipc structure if found or NULL >>+ * if not. >>+ * If key is found ipc contains its ipc structure >> */ >> >>-int ipc_findkey(struct ipc_ids* ids, key_t key) >>+struct kern_ipc_perm *ipc_findkey(struct ipc_ids *ids, key_t key) >> { >>- int id; >>- struct kern_ipc_perm* p; >>- int max_id = ids->max_id; >>+ struct kern_ipc_perm *ipc; >>+ struct kern_ipc_perm *ipcs[IPCS_MAX_SCAN_ENTRIES]; > > > ... together with this means 4*256 -> 1k of precious stack space used. > Please consider either lowering IPCS_MAX_SCAN_ENTRIES or kmalloc() that. > > Same problem with your third patch called > "Changing the loops on a single ipcid into radix_tree_gang_lookup() calls" > > If you cannot sleep, try to lower that constant (e.g. 16-32). > The current users use much smaller numbers. > > If you can sleep and performance goes down after lowering that constant, > try to kmalloc these arrays (since kmalloc() of that small amount > should succeed easily). > > > > Regards > > Ingo Oeser >
Ingo,
You're completely right, but trying to lower the extraction size, I'm afraid this will have an impact on performances.
Here are the results of a small test I did: I have run ctxbench on both the 256 and and 16 entries versions
1) 256 entries:
[root@akt ctxbench-1.9]# echo 1000 > /proc/sys/kernel/msgmni [root@akt ctxbench-1.9]# ./ctx -m -t300
Context switching benchmark v1.17 Using message queue for IPC control Max iterations: 0 (zero = no limit) Max runtime (sec): 300 (zero = no limit) 42523679 itterations in 300.005423 seconds = 141743/sec
2) 16 entries:
[root@akt ctxbench-1.9]# echo 1000 > /proc/sys/kernel/msgmni [root@akt ctxbench-1.9]# ./ctx -m -t300
Context switching benchmark v1.17 Using message queue for IPC control Max iterations: 0 (zero = no limit) Max runtime (sec): 300 (zero = no limit) 41774255 itterations in 300.005334 seconds = 139245/sec
Will try with a dynamic allocation.
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/
| |