From: Waiman Long <waiman.long@hp.com>
To: Stephen Smalley <sds@tycho.nsa.gov>,
James Morris <james.l.morris@oracle.com>,
Eric Paris <eparis@parisplace.org>
Cc: linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, "Chandramouleeswaran,
Aswin" <aswin@hp.com>, "Norton, Scott J" <scott.norton@hp.com>
Subject: Re: [PATCH RFC 1/2] SELinux: reduce overhead of mls_level_isvalid() function call
Date: Wed, 05 Jun 2013 10:53:13 -0400 [thread overview]
Message-ID: <51AF50D9.5060006@hp.com> (raw)
In-Reply-To: <5183C4BE.5030504@hp.com>
On 05/03/2013 10:07 AM, Waiman Long wrote:
> On 04/10/2013 02:26 PM, Waiman Long wrote:
>> While running the high_systime workload of the AIM7 benchmark on
>> a 2-socket 12-core Westmere x86-64 machine running 3.8.2 kernel,
>> it was found that a pretty sizable amount of time was spent in the
>> SELinux code. Below was the perf trace of the "perf record -a -s"
>> of a test run at 1500 users:
>>
>> 3.96% ls [kernel.kallsyms] [k] ebitmap_get_bit
>> 1.44% ls [kernel.kallsyms] [k] mls_level_isvalid
>> 1.33% ls [kernel.kallsyms] [k] find_next_bit
>>
>> The ebitmap_get_bit() was the hottest function in the perf-report
>> output. Both the ebitmap_get_bit() and find_next_bit() functions
>> were, in fact, called by mls_level_isvalid(). As a result, the
>> mls_level_isvalid() call consumed 6.73% of the total CPU time of all
>> the 24 virtual CPUs which is quite a lot.
>>
>> Looking at the mls_level_isvalid() function, it is checking to see
>> if all the bits set in one of the ebitmap structure are also set in
>> another one as well as the highest set bit is no bigger than the one
>> specified by the given policydb data structure. It is doing it in
>> a bit-by-bit manner. So if the ebitmap structure has many bits set,
>> the iteration loop will be done many times.
>>
>> The current code can be rewritten to use a similar algorithm as the
>> ebitmap_contains() function with an additional check for the highest
>> set bit. With that change, the perf trace showed that the used CPU
>> time drop down to just 0.09% of the total which is about 100X less
>> than before.
>>
>> 0.04% ls [kernel.kallsyms] [k] ebitmap_get_bit
>> 0.04% ls [kernel.kallsyms] [k] mls_level_isvalid
>> 0.01% ls [kernel.kallsyms] [k] find_next_bit
>>
>> Actually, the remaining ebitmap_get_bit() and find_next_bit() function
>> calls are made by other kernel routines as the new mls_level_isvalid()
>> function will not call them anymore.
>>
>> This patch also improves the high_systime AIM7 benchmark result,
>> though the improvement is not as impressive as is suggested by the
>> reduction in CPU time. The table below shows the performance change
>> on the 2-socket x86-64 system mentioned above.
>>
>> +--------------+---------------+----------------+-----------------+
>> | Workload | mean % change | mean % change | mean % change |
>> | | 10-100 users | 200-1000 users | 1100-2000 users |
>> +--------------+---------------+----------------+-----------------+
>> | high_systime | +0.2% | +1.1% | +2.4% |
>> +--------------+---------------+----------------+-----------------+
>>
>> Signed-off-by: Waiman Long<Waiman.Long@hp.com>
>> ---
>> security/selinux/ss/mls.c | 38
>> +++++++++++++++++++++++++++-----------
>> 1 files changed, 27 insertions(+), 11 deletions(-)
>>
>> diff --git a/security/selinux/ss/mls.c b/security/selinux/ss/mls.c
>> index 40de8d3..ce02803 100644
>> --- a/security/selinux/ss/mls.c
>> +++ b/security/selinux/ss/mls.c
>> @@ -160,8 +160,7 @@ void mls_sid_to_context(struct context *context,
>> int mls_level_isvalid(struct policydb *p, struct mls_level *l)
>> {
>> struct level_datum *levdatum;
>> - struct ebitmap_node *node;
>> - int i;
>> + struct ebitmap_node *nodel, *noded;
>>
>> if (!l->sens || l->sens> p->p_levels.nprim)
>> return 0;
>> @@ -170,16 +169,33 @@ int mls_level_isvalid(struct policydb *p,
>> struct mls_level *l)
>> if (!levdatum)
>> return 0;
>>
>> - ebitmap_for_each_positive_bit(&l->cat, node, i) {
>> - if (i> p->p_cats.nprim)
>> - return 0;
>> - if (!ebitmap_get_bit(&levdatum->level->cat, i)) {
>> - /*
>> - * Category may not be associated with
>> - * sensitivity.
>> - */
>> - return 0;
>> + /*
>> + * Return 1 iff
>> + * 1. l->cat.node is NULL, or
>> + * 2. all the bits set in l->cat are also set in
>> levdatum->level->cat,
>> + * and
>> + * 3. the last bit set in l->cat should not be larger than
>> + * p->p_cats.nprim.
>> + */
>> + noded = levdatum->level->cat.node;
>> + for (nodel = l->cat.node ; nodel ; nodel = nodel->next) {
>> + int i, lastsetbit = -1;
>> +
>> + for (i = EBITMAP_UNIT_NUMS - 1 ; i>= 0 ; i--) {
>> + if (!nodel->maps[i])
>> + continue;
>> + if (!noded ||
>> + ((nodel->maps[i]&noded->maps[i]) != nodel->maps[i]))
>> + return 0;
>> + if (lastsetbit< 0)
>> + lastsetbit = nodel->startbit +
>> + i * EBITMAP_UNIT_SIZE +
>> + __fls(nodel->maps[i]);
>> }
>> + if ((lastsetbit>= 0)&& (lastsetbit> p->p_cats.nprim))
>> + return 0;
>> + if (noded)
>> + noded = noded->next;
>> }
>>
>> return 1;
>
> Would you mind giving me some feedback on what you think about this
> patch?
>
> Thank a lot!
> Regards,
> Longman
I am sorry for the annoyance, but I really want to have some feedback
on whether this patch is viable or not.
Thanks,
Longman
next prev parent reply other threads:[~2013-06-05 14:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-10 18:26 [PATCH RFC 1/2] SELinux: reduce overhead of mls_level_isvalid() function call Waiman Long
2013-04-10 18:26 ` [PATCH RFC 2/2] SELinux: Increase ebitmap_node size for 64-bit configuration Waiman Long
2013-05-03 14:07 ` [PATCH RFC 1/2] SELinux: reduce overhead of mls_level_isvalid() function call Waiman Long
2013-06-05 14:53 ` Waiman Long [this message]
2013-06-05 14:59 ` Stephen Smalley
2013-06-05 15:18 ` Waiman Long
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=51AF50D9.5060006@hp.com \
--to=waiman.long@hp.com \
--cc=aswin@hp.com \
--cc=eparis@parisplace.org \
--cc=james.l.morris@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=scott.norton@hp.com \
--cc=sds@tycho.nsa.gov \
/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