summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorDavidlohr Bueso <dave@stgolabs.net>2017-11-17 15:31:18 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2017-11-17 16:10:04 -0800
commit15df03c87983660a4d1eedb4541778592bd97684 (patch)
treefb8e7ae25cee35177eb45e11bb3435f79ccc009f /include
parentebf66799acfb5f52ada4ff96ecc9579867941ea9 (diff)
sysvipc: make get_maxid O(1) again
For a custom microbenchmark on a 3.30GHz Xeon SandyBridge, which calls IPC_STAT over and over, it was calculated that, on avg the cost of ipc_get_maxid() for increasing amounts of keys was: 10 keys: ~900 cycles 100 keys: ~15000 cycles 1000 keys: ~150000 cycles 10000 keys: ~2100000 cycles This is unsurprising as maxid is currently O(n). By having the max_id available in O(1) we save all those cycles for each semctl(_STAT) command, the idr_find can be expensive -- which some real (customer) workloads actually poll on. Note that this used to be the case, until commit 7ca7e564e04 ("ipc: store ipcs into IDRs"). The cost is the extra idr_find when doing RMIDs, but we simply go backwards, and should not take too many iterations to find the new value. [akpm@linux-foundation.org: coding-style fixes] Link: http://lkml.kernel.org/r/20170831172049.14576-5-dave@stgolabs.net Signed-off-by: Davidlohr Bueso <dbueso@suse.de> Cc: Manfred Spraul <manfred@colorfullife.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'include')
-rw-r--r--include/linux/ipc_namespace.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/include/linux/ipc_namespace.h b/include/linux/ipc_namespace.h
index d7cf3a850853..b5630c8eb2f3 100644
--- a/include/linux/ipc_namespace.h
+++ b/include/linux/ipc_namespace.h
@@ -19,6 +19,7 @@ struct ipc_ids {
bool tables_initialized;
struct rw_semaphore rwsem;
struct idr ipcs_idr;
+ int max_id;
#ifdef CONFIG_CHECKPOINT_RESTORE
int next_id;
#endif