Messages in this thread | | | Date | Thu, 29 Mar 2012 15:44:08 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [PATCH 4/6] trace: trace syscall in its handler not from ptrace handler |
| |
On 03/29/2012 03:40 PM, David Sharp wrote: > On Thu, Mar 29, 2012 at 1:06 PM, H. Peter Anvin <hpa@zytor.com> wrote: >> I had a long discussion with Frederic over IRC earlier today. We came >> up with the following strawman: >> >> 1. A system call thunk (which could be enabled/disabled by patching the >> syscall table.) This provides an entry and exit hook, and also sets a >> per-thread flag to capture userspace traffic. > > Our goal is for syscall traces to be as fast as regular tracepoints. > iirc, What we've found is that much of the extra overhead of syscall > tracepoints as compared to regular tracepoints is due to that the code > path for syscall tracing is bundled with checks for ptrace and other > stuff (Vaibhav did all this characterization, he can jump in with > details if wanted). How much work would this "thunk" have to do that > is not either recording the trace or calling the syscall?
Nothing. That IS what the thunk would do:
thunk: <record syscall entry> call real_syscall_table(syscall_number) <record syscall exit> ret
-hpa
| |