From: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
To: <linux-kernel@vger.kernel.org>
Cc: <john.johansen@canonical.com>, <paul@paul-moore.com>,
<jmorris@namei.org>, <serge@hallyn.com>,
<linux-security-module@vger.kernel.org>, <gautham.shenoy@amd.com>,
<Santosh.Shukla@amd.com>, <Ananth.Narayan@amd.com>,
<Raghavendra.KodsaraThimmappa@amd.com>, <paulmck@kernel.org>,
<boqun.feng@gmail.com>, <vinicius.gomes@intel.com>,
<mjguzik@gmail.com>, <dennis@kernel.org>, <tj@kernel.org>,
<cl@linux.com>, <linux-mm@kvack.org>, <rcu@vger.kernel.org>
Subject: [RFC 6/6] apparmor: Switch labels to percpu ref managed mode
Date: Mon, 16 Sep 2024 10:38:11 +0530 [thread overview]
Message-ID: <20240916050811.473556-7-Neeraj.Upadhyay@amd.com> (raw)
In-Reply-To: <20240916050811.473556-1-Neeraj.Upadhyay@amd.com>
Nginx performance testing with Apparmor enabled (with Nginx running in
unconfined profile), on kernel versions 6.1 and 6.5 show significant
drop in throughput scalability when Nginx workers are scaled to use
higher number of CPUs across various L3 cache domains.
Below is one sample data on the throughput scalability loss, based on
results on AMD Zen4 system with 96 CPUs with SMT core count 2:
Config Cache Domains apparmor=off apparmor=on
scaling eff (%) scaling eff (%)
8C16T 1 100% 100%
16C32T 2 95% 94%
24C48T 3 94% 93%
48C96T 6 92% 88%
96C192T 12 85% 68%
There is a significant drop in scaling efficiency for 96 cores/192 SMT
threads.
Perf tool shows most of the contention coming from below places:
6.56% nginx [kernel.vmlinux] [k] apparmor_current_getsecid_subj
6.22% nginx [kernel.vmlinux] [k] apparmor_file_open
The majority of the CPU cycles is found to be due to memory contention
in atomic_fetch_add and atomic_fetch_sub operations from kref_get() and
kref_put() operations on AppArmor labels.
A part of the contention was fixed with commit 2516fde1fa00 ("apparmor:
Optimize retrieving current task secid"). After including this commit, the
scaling efficiency improved to below:
Config Cache Domains apparmor=on apparmor=on (patched)
scaling eff (%) scaling eff (%)
8C16T 1 100% 100%
16C32T 2 97% 93%
24C48T 3 94% 92%
48C96T 6 88% 88%
96C192T 12 65% 79%
However, the scaling efficiency impact is still significant even after
including the commit. Also, the performance impact is even higher for
>192 CPUs. In addition, the memory contention impact would increase
when there is a high frequency of label update operations and labels
are marked stale more frequently.
Use the new percpu managed mode for tracking release of all Apparmor
labels. Using percpu refcount for Apparmor label's refcounting improves
throughput scalability for Nginx:
Config Cache Domains apparmor=on (percpuref)
scaling eff (%)
8C16T 1 100%
16C32T 2 96%
24C48T 3 94%
48C96T 6 93%
96C192T 12 90%
Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
---
The apparmor_file_open() refcount contention has been resolved recently
with commit f4fee216df7d ("apparmor: try to avoid refing the label in
apparmor_file_open"). I have posted this series to get feedback on the
approach to improve refcount scalability within apparmor subsystem.
security/apparmor/label.c | 1 +
security/apparmor/policy_ns.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/security/apparmor/label.c b/security/apparmor/label.c
index aa9e6eac3ecc..016a45a180b1 100644
--- a/security/apparmor/label.c
+++ b/security/apparmor/label.c
@@ -710,6 +710,7 @@ static struct aa_label *__label_insert(struct aa_labelset *ls,
rb_link_node(&label->node, parent, new);
rb_insert_color(&label->node, &ls->root);
label->flags |= FLAG_IN_TREE;
+ percpu_ref_switch_to_managed(&label->count);
return aa_get_label(label);
}
diff --git a/security/apparmor/policy_ns.c b/security/apparmor/policy_ns.c
index 1f02cfe1d974..18eb58b68a60 100644
--- a/security/apparmor/policy_ns.c
+++ b/security/apparmor/policy_ns.c
@@ -124,6 +124,7 @@ static struct aa_ns *alloc_ns(const char *prefix, const char *name)
goto fail_unconfined;
/* ns and ns->unconfined share ns->unconfined refcount */
ns->unconfined->ns = ns;
+ percpu_ref_switch_to_managed(&ns->unconfined->label.count);
atomic_set(&ns->uniq_null, 0);
@@ -377,6 +378,7 @@ int __init aa_alloc_root_ns(void)
}
kernel_t = &kernel_p->label;
root_ns->unconfined->ns = aa_get_ns(root_ns);
+ percpu_ref_switch_to_managed(&root_ns->unconfined->label.count);
return 0;
}
--
2.34.1
next prev parent reply other threads:[~2024-09-16 5:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-16 5:08 [RFC 0/6] Managed Percpu Refcount Neeraj Upadhyay
2024-09-16 5:08 ` [RFC 1/6] percpu-refcount: Add managed mode for RCU released objects Neeraj Upadhyay
2024-09-16 5:08 ` [RFC 2/6] percpu-refcount: Add torture test for percpu refcount Neeraj Upadhyay
2024-09-16 5:08 ` [RFC 3/6] percpu-refcount: Extend managed mode to allow runtime switching Neeraj Upadhyay
2024-09-16 5:08 ` [RFC 4/6] percpu-refcount-torture: Extend test with runtime mode switches Neeraj Upadhyay
2024-09-16 5:08 ` [RFC 5/6] apparmor: Switch labels to percpu refcount in atomic mode Neeraj Upadhyay
2024-09-16 5:08 ` Neeraj Upadhyay [this message]
2024-09-18 5:44 ` [RFC 6/6] apparmor: Switch labels to percpu ref managed mode kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240916050811.473556-7-Neeraj.Upadhyay@amd.com \
--to=neeraj.upadhyay@amd.com \
--cc=Ananth.Narayan@amd.com \
--cc=Raghavendra.KodsaraThimmappa@amd.com \
--cc=Santosh.Shukla@amd.com \
--cc=boqun.feng@gmail.com \
--cc=cl@linux.com \
--cc=dennis@kernel.org \
--cc=gautham.shenoy@amd.com \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mjguzik@gmail.com \
--cc=paul@paul-moore.com \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=tj@kernel.org \
--cc=vinicius.gomes@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).