Ingo Oeser wrote:
Hi Nadia,
good to see someone is pounding this old beast again :-)
On Thursday 07 June 2007, [email protected] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
