lkml.org 
[lkml]   [2011]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC] Proposal for ptrace improvements
    On Fri, Mar 4, 2011 at 3:40 PM, Tejun Heo <tj@kernel.org> wrote:
    > On Fri, Mar 04, 2011 at 03:31:15PM +0100, Denys Vlasenko wrote:
    >> On Fri, Mar 4, 2011 at 3:07 PM, Tejun Heo <tj@kernel.org> wrote:
    >> > Hello,
    >> >
    >> > On Fri, Mar 04, 2011 at 02:59:32PM +0100, Denys Vlasenko wrote:
    >> >> I would rather speed strace up than slow it down further, even if
    >> >> slightly.
    >> >
    >> > The question to ask is at what cost?  If mostly unnoticeable slow down
    >> > makes the API cleaner, I'll go that way.  Everything is a tradeoff.
    >>
    >> # time sh -c 'ls -lR /usr/share >/dev/null'
    >> real  0m2.633s
    >>
    >> strace without PTRACE_GETSIGINFO:
    >> real  0m47.023s
    >> real  0m48.799s
    >> real  0m47.695s
    >>
    >> strace with PTRACE_GETSIGINFO:
    >> real  0m51.958s
    >> real  0m53.773s
    >> real  0m51.625s
    >
    > Great, numbers, so it's ~10 slow down.  Gees, with or without that
    > change, strace(2) is heavy, >18 times slower than without.

    Here's a typical sequence of operations strace is doing:

    wait4(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGTRAP}], __WALL, NULL) = 10445
    ptrace(PTRACE_GETSIGINFO, 10445, 0, {si_signo=SIGTRAP, si_code=0x5,
    si_pid=10445, si_uid=0, si_value={int=0, ptr=0}}) = 0
    ptrace(PTRACE_PEEKUSER, 10445, 8*ORIG_RAX, [0x36]) = 0
    ptrace(PTRACE_PEEKUSER, 10445, 8*CS, [0x23]) = 0
    ptrace(PTRACE_PEEKUSER, 10445, 8*RAX, [0xffffffffffffffda]) = 0
    ptrace(PTRACE_PEEKUSER, 10445, 8*RBX, [0x1]) = 0
    ptrace(PTRACE_PEEKUSER, 10445, 8*RCX, [0x5401]) = 0
    ptrace(PTRACE_PEEKUSER, 10445, 8*RDX, [0xffb83f10]) = 0
    ptrace(PTRACE_SYSCALL, 10445, 0x1, SIG_0) = 0

    IOW: strace wastes a lot of time just transiting to the kernel and back
    with simple syscalls to get the information.

    What would help here is a "vectorized" waitpid operation
    which retrieves much more information in one go:

    waitpid_vec(int max_results, int status_vector[], siginfo_t
    si_vector[], struct pt_regs reg_vector[])

    --
    vda
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-03-06 11:19    [W:4.027 / U:2.552 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site