summaryrefslogtreecommitdiffstats
path: root/security/apparmor
diff options
context:
space:
mode:
authorEric Dumazet <edumazet@google.com>2015-06-30 15:54:08 +0200
committerAl Viro <viro@zeniv.linux.org.uk>2015-07-01 02:30:09 -0400
commit8a81252b774b53e628a8a0fe18e2b8fc236d92cc (patch)
tree2176cd782e2b578da7ac1072f4430bf68e22c274 /security/apparmor
parent1af95de6f0119d5bde02d3a811a9f3a3661e954e (diff)
downloadop-kernel-dev-8a81252b774b53e628a8a0fe18e2b8fc236d92cc.zip
op-kernel-dev-8a81252b774b53e628a8a0fe18e2b8fc236d92cc.tar.gz
fs/file.c: don't acquire files->file_lock in fd_install()
Mateusz Guzik reported : Currently obtaining a new file descriptor results in locking fdtable twice - once in order to reserve a slot and second time to fill it. Holding the spinlock in __fd_install() is needed in case a resize is done, or to prevent a resize. Mateusz provided an RFC patch and a micro benchmark : http://people.redhat.com/~mguzik/pipebench.c A resize is an unlikely operation in a process lifetime, as table size is at least doubled at every resize. We can use RCU instead of the spinlock. __fd_install() must wait if a resize is in progress. The resize must block new __fd_install() callers from starting, and wait that ongoing install are finished (synchronize_sched()) resize should be attempted by a single thread to not waste resources. rcu_sched variant is used, as __fd_install() and expand_fdtable() run from process context. It gives us a ~30% speedup using pipebench on a dual Intel(R) Xeon(R) CPU E5-2696 v2 @ 2.50GHz Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Mateusz Guzik <mguzik@redhat.com> Acked-by: Mateusz Guzik <mguzik@redhat.com> Tested-by: Mateusz Guzik <mguzik@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'security/apparmor')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud