sysvipc: make get_maxid O(1) again
authorDavidlohr Bueso <[email protected]>
Fri, 17 Nov 2017 23:31:18 +0000 (15:31 -0800)
committerLinus Torvalds <[email protected]>
Sat, 18 Nov 2017 00:10:04 +0000 (16:10 -0800)
commit15df03c87983660a4d1eedb4541778592bd97684
treefb8e7ae25cee35177eb45e11bb3435f79ccc009f
parentebf66799acfb5f52ada4ff96ecc9579867941ea9
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.

[[email protected]: coding-style fixes]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Davidlohr Bueso <[email protected]>
Cc: Manfred Spraul <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
include/linux/ipc_namespace.h
ipc/util.c
ipc/util.h