[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTin-9SmqB=U7gmOFY2qkCLNd_Yn-sw@mail.gmail.com>
Date: Fri, 13 May 2011 09:29:27 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Serge E. Hallyn" <serge@...lyn.com>
Cc: "Serge E. Hallyn" <serge.hallyn@...onical.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Daniel Lezcano <daniel.lezcano@...e.fr>,
David Howells <dhowells@...hat.com>,
James Morris <jmorris@...ei.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
containers@...ts.linux-foundation.org,
Al Viro <viro@...iv.linux.org.uk>
Subject: Re: acl_permission_check: disgusting performance
On Fri, May 13, 2011 at 9:16 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Looks ok to me. And generates good code for acl_permission_check
> without CONFIG_USER_NS.
>
> I'll see how much that function drops on the kernel profiles..
Yup, looking good.
For my "kernel make with no changes" workload, it dropped from
1.28% make [kernel.kallsyms] [k] acl_permission_check
to
0.88% make [kernel.kallsyms] [k]
acl_permission_check
which is pretty much exactly the expected 30% drop from no longer
having that expensive load of user_ns.
Of course, that 30% improvement is just a 0.4% performance improvement
in the big picture, but hey, almost half a percentage point on a real
load from just one single function in the kernel is definitely worth
doing.
Do you want to carry this for 2.6.40, or should I just apply it?
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