[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 7 Jul 2008 09:34:06 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Roland McGrath <roland@...hat.com>
cc: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Alexander Viro <aviro@...hat.com>,
Eric Paris <eparis@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] x86_64 ia32 syscall audit fast-path
On Sun, 6 Jul 2008, Roland McGrath wrote:
>
> This adds fast paths for 32-bit syscall entry and exit when
> TIF_SYSCALL_AUDIT is set, but no other kind of syscall tracing.
> These paths does not need to save and restore all registers as
> the general case of tracing does. Avoiding the iret return path
> when syscall audit is enabled helps performance a lot.
Please don't do it like this.
I realize that Fedora enables audit by default, and that you care about
the speed of the audit path, but I care about the speed of the *non*audit
path. And you just slowed it down unnecessarily.
> TRACE_IRQS_OFF
> - testl $_TIF_ALLWORK_MASK,threadinfo_flags(%r10)
> + testl $(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT),threadinfo_flags(%r10)
> jnz int_ret_from_sys_call
> + bt $TIF_SYSCALL_AUDIT,threadinfo_flags(%r10)
> + jc sysexit_audit
Please don't add more instructions to the fastpath. Especially not
relatively slow ones like 'bt'.
So keep the
testl $_TIF_ALLWORK_MASK,threadinfo_flags(%r10)
jnz audit_or_other_work
and then in that *slow*path in int_ret_from_sys_call, do
audit_or_other_work:
testl $(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT),threadinfo_flags(%r10)
jnz int_ret_from_sys_call
sysexit_audit:
....
so that we don't have any extra costs at all for the non-audit case.
I realize that maybe you don't care too much about the ia32 emulation, but
it's going to be the common case for some distros (I think several distros
end up with a 32-bit user space even when they use a 64-bit kernel).
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