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-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html