Message-ID: <CA+55aFyiOR=2o7BWQXcb-7_YULXbr+SuzoOeGQxV4cmck1y8Ow@mail.gmail.com>
Date:	Sat, 25 May 2013 22:19:51 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	James Morris <jmorris@...ei.org>
Cc:	Casey Schaufler <casey@...aufler-ca.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Eric Paris <eparis@...hat.com>,
	James Morris <james.l.morris@...cle.com>
Subject: Re: Stupid VFS name lookup interface..

On Sat, May 25, 2013 at 10:04 PM, James Morris <jmorris@...ei.org> wrote:
> On Sat, 25 May 2013, Linus Torvalds wrote:
>
>> But I haven't even looked at what non-selinux setups do to
>> performance. Last time I tried Ubuntu (they still use apparmor, no?),
>> "make modules_install ; make install" didn't work for the kernel, and
>> if the Ubuntu people don't want to support kernel engineers, I
>> certainly am not going to bother with them. Who uses smack?
>
> Tizen, perhaps a few others.

Btw, it really would be good if security people started realizing that
performance matters. It's annoying to see the security lookups cause
50% performance degradations on pathname lookup (and no, I'm not
exaggerating, that's literally what it was before we fixed it - and
no, by "we" I don't mean security people).

There's a really simple benchmark that is actually fairly relevant:
build a reasonable kernel ("make localmodconfig" or similar - not the
normal distro kernel that has everything enabled) without debugging or
other crud enabled, run that kernel, and then re-build the fully built
kernel to make sure it's all in the disk cache. Then, when you don't
need any IO, and don't need to recompile anything, do a "make -j".

Assuming you have a reasonably modern desktop machine, it should take
something like 5-10 seconds, of which almost everything is just "make"
doing lots of stat() calls to see that everything is fully built. If
it takes any longer, you're doing something wrong.

Once you are at that point, just do "perf record -f -e cycles:pp make
-j" and then "perf report" on the thing.

(The "-e cycles:pp" is not necessary for the rough information, but it
helps if you then want to go and annotate the assembler to see where
the costs come from).

If you see security functions at the top, you know that the security
routines take more time than the real work the kernel is doing, and
should realize that that would be a problem.

Right now (zooming into the kernel only - ignoring the fact that make
really spends a fair amount of time in user space) I get

  9.79%      make  [k] __d_lookup_rcu
  5.48%      make  [k] link_path_walk
  2.94%      make  [k] avc_has_perm_noaudit
  2.47%      make  [k] selinux_inode_permission
  2.25%      make  [k] path_lookupat
  1.89%      make  [k] generic_fillattr
  1.50%      make  [k] lookup_fast
  1.27%      make  [k] copy_user_generic_string
  1.17%      make  [k] generic_permission
  1.15%      make  [k] dput
  1.12%      make  [k] inode_has_perm.constprop.58
  1.11%      make  [k] __inode_permission
  1.08%      make  [k] kmem_cache_alloc
  ...

so the permission checking is certainly quite noticeable, but it's by
no means dominant. This is with both of the patches I've posted, but
the numbers weren't all that different before (inode_has_perm and
selinux_inode_permission used to be higher up in the list, now
avc_has_perm_noaudit is the top selinux cost - which actually makes
some amount of sense).

So it's easy to have a fairly real-world performance profile that
shows path lookup costs on a real test.

                  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists