diff options
author | Roland Dreier <rolandd@cisco.com> | 2006-06-17 20:44:49 -0700 |
---|---|---|
committer | Roland Dreier <rolandd@cisco.com> | 2006-06-17 20:44:49 -0700 |
commit | 9ead190bfde2a434c74ea604382d08acb2eceef5 (patch) | |
tree | 937f1bb8dedea56efc46aed12370bb3865898763 /Documentation | |
parent | c93b6fbaa99bb3a1552e14317296be14dde51dfb (diff) | |
download | linux-9ead190bfde2a434c74ea604382d08acb2eceef5.tar.gz linux-9ead190bfde2a434c74ea604382d08acb2eceef5.tar.bz2 linux-9ead190bfde2a434c74ea604382d08acb2eceef5.zip |
IB/uverbs: Don't serialize with ib_uverbs_idr_mutex
Currently, all userspace verbs operations that call into the kernel
are serialized by ib_uverbs_idr_mutex. This can be a scalability
issue for some workloads, especially for devices driven by the ipath
driver, which needs to call into the kernel even for datapath
operations.
Fix this by adding reference counts to the userspace objects, and then
converting ib_uverbs_idr_mutex into a spinlock that only protects the
idrs long enough to take a reference on the object being looked up.
Because remove operations may fail, we have to do a slightly funky
two-step deletion, which is described in the comments at the top of
uverbs_cmd.c.
This also still leaves ib_uverbs_idr_lock as a single lock that is
possibly subject to contention. However, the lock hold time will only
be a single idr operation, so multiple threads should still be able to
make progress, even if ib_uverbs_idr_lock is being ping-ponged.
Surprisingly, these changes even shrink the object code:
add/remove: 23/5 grow/shrink: 4/21 up/down: 633/-693 (-60)
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions