On Sun, May 20, 2012 at 09:40:42AM +0100, Al Viro wrote:
> Moreover, checking PT_TRACED first is not even cheaper in the common case
> (i.e. when branch to .Ltracesys is not taken at all). As it is, parisc does
> mfctl %cr30, %r1
> LDREG TI_TASK(%r1),%r1
> ldw TASK_PTRACE(%r1), %r1
> bb,<,n %r1,31,.Ltracesys
> and that's actually an extra dereference compared to
> mfctl %cr30, %r1
> LDREG TI_FLAGS(%r1),%r1
> bb,<,n %r1,31 - TIF_SYSCALL_TRACE,.Ltracesys
> Note that tracehook_report_syscall_entry/tracehook_report_syscall_exit
> are checking PT_PTRACED, so it's not like we needed to change anything
> other than that spot - resulting logics will be equivalent to what we
> have right now. Looks like a fairly straightforward optimisation...
> Am I missing something subtle and parisc-specific here?
Actually, looks like I am missing something, but it's not particulary subtle.
SYSCALL_TRACE is needed for do_syscall_trace_enter() to do anything;
any of SYSCALL_TRACE/SINGLESTEP/BLOCKSTEP is makes do_syscall_trace_leave()
do things. So checking one bit in flags is not enough - any of those 3 is
a reason for taking the slow path. The point still stands, though -
mfctl %cr30, %r1
LDREG TI_FLAGS(%r1),%r1
ldi (_TIF_SYSCALL_TRACE | _TIF_SINGLESTEP | _TIF_BLOCKSTEP), %r19
and,COND(=) %r19, %r1, %r0
b,n .Ltracesys
would still be no worse on the fast path and would not hit the slow path in
a lot of cases when the current code does it for no apparent reason.
Comments?
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
