From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Mateusz Guzik <mjguzik@gmail.com>,
John Johansen <john.johansen@canonical.com>
Cc: linux-security-module@vger.kernel.org, apparmor@lists.ubuntu.com,
linux-kernel@vger.kernel.org
Subject: Re: [apparmor] use per-cpu refcounts for apparmor labels?
Date: Mon, 25 Sep 2023 16:49:25 -0700 [thread overview]
Message-ID: <87a5t9bypm.fsf@intel.com> (raw)
In-Reply-To: <CAGudoHFfG7mARwSqcoLNwV81-KX4Bici5FQHjoNG4f9m83oLyg@mail.gmail.com>
Hi Mateusz,
Mateusz Guzik <mjguzik@gmail.com> writes:
> I'm sanity-checking perf in various microbenchmarks and I found
> apparmor to be the main bottleneck in some of them.
>
> For example: will-it-scale open1_processes -t 16, top of the profile:
> 20.17% [kernel] [k] apparmor_file_alloc_security
> 20.08% [kernel] [k] apparmor_file_open
> 20.05% [kernel] [k] apparmor_file_free_security
> 18.39% [kernel] [k] apparmor_current_getsecid_subj
> [snip]
>
> This serializes on refing/unrefing apparmor objs, sounds like a great
> candidate for per-cpu refcounting instead (I'm assuming they are
> expected to be long-lived).
>
> I would hack it up myself, but I failed to find a clear spot to switch
> back from per-cpu to centalized operation and don't want to put
> serious effort into it.
>
> Can you sort this out?
I was looking at this same workload, and proposed a patch[1] some time
ago, see if it helps:
https://lists.ubuntu.com/archives/apparmor/2023-August/012914.html
But my idea was different, in many cases, we are looking at the label
associated with the current task, and there's no need to take the
refcount.
>
> Thanks,
> --
> Mateusz Guzik <mjguzik gmail.com>
>
Cheers,
--
Vinicius
next prev parent reply other threads:[~2023-09-25 23:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-22 21:19 use per-cpu refcounts for apparmor labels? Mateusz Guzik
2023-09-25 23:49 ` Vinicius Costa Gomes [this message]
2023-09-26 6:21 ` [apparmor] " John Johansen
2023-09-26 6:38 ` Mateusz Guzik
2023-09-26 12:48 ` John Johansen
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=87a5t9bypm.fsf@intel.com \
--to=vinicius.gomes@intel.com \
--cc=apparmor@lists.ubuntu.com \
--cc=john.johansen@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mjguzik@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.