selinux: mark selinux_xfrm_refcount as __read_mostly
authorOndrej Mosnacek <omosnace@redhat.com>
Wed, 6 Jan 2021 13:26:22 +0000 (14:26 +0100)
committerPaul Moore <paul@paul-moore.com>
Tue, 12 Jan 2021 15:12:58 +0000 (10:12 -0500)
commite0de8a9aebd01589c0246facf1eb533dd1b7a506
treea3e060e879ff7b9b3b713d12bbff8caedc1df527
parentcd2bb4cb0996f73ad31604d86c1c0815fc813349
selinux: mark selinux_xfrm_refcount as __read_mostly

This is motivated by a perfomance regression of selinux_xfrm_enabled()
that happened on a RHEL kernel due to false sharing between
selinux_xfrm_refcount and (the late) selinux_ss.policy_rwlock (i.e. the
.bss section memory layout changed such that they happened to share the
same cacheline). Since the policy rwlock's memory region was modified
upon each read-side critical section, the readers of
selinux_xfrm_refcount had frequent cache misses, eventually leading to a
significant performance degradation under a TCP SYN flood on a system
with many cores (32 in this case, but it's detectable on less cores as
well).

While upstream has since switched to RCU locking, so the same can no
longer happen here, selinux_xfrm_refcount could still share a cacheline
with another frequently written region, thus marking it __read_mostly
still makes sense. __read_mostly helps, because it will put the symbol
in a separate section along with other read-mostly variables, so there
should never be a clash with frequently written data.

Since selinux_xfrm_refcount is modified only in case of an explicit
action, it should be safe to do this (i.e. it shouldn't disrupt other
read-mostly variables too much).

Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
security/selinux/xfrm.c