lkml.org 
[lkml]   [2007]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch-early-RFC 00/10] LTTng architecture dependent instrumentation
    * Ingo Molnar (mingo@elte.hu) wrote:
    >
    > hi Mathieu,
    >
    > * Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
    >
    > > Hi,
    > >
    > > Here is the architecture dependent instrumentation for LTTng. [...]
    >
    > A fundamental observation about markers, and i raised this point many
    > many months ago already, so it might sound repetitive, but i'm unsure
    > wether it's addressed. Documentation/markers.txt still says:
    >
    > | * Purpose of markers
    > |
    > | A marker placed in code provides a hook to call a function (probe)
    > | that you can provide at runtime. A marker can be "on" (a probe is
    > | connected to it) or "off" (no probe is attached). When a marker is
    > | "off" it has no effect, except for adding a tiny time penalty
    > | (checking a condition for a branch) and space penalty (adding a few
    > | bytes for the function call at the end of the instrumented function
    > | and adds a data structure in a separate section).
    >
    > could you please eliminate the checking of the flag, and insert a pure
    > NOP sequence by default (no extra branches), which is then patched in
    > with a function call instruction sequence, when the trace point is
    > turned on? (on architectures that have code patching infrastructure -
    > such as x86)
    >

    Hi Ingo,

    Here are the results of a test I made, hacking a binary to put nops
    instead of a function call.

    The test is 20000 loops calling a function that contains a marker with
    interrupts disabled. It is performed on a x86 32, Pentium 4 3GHz.

    __my_trace_mark(0, kernel_debug_test, NULL, "%d %d %ld %ld", 2, current->pid,
    arg, arg2);

    The number here include the function call (present in both cases) the
    counter increment/tests and the marker.

    * No marker at all

    240300 cycles total
    12.02 cycles per loop

    void test(unsigned long arg, unsigned long arg2)
    {
    0: 55 push %ebp
    1: 89 e5 mov %esp,%ebp
    asm volatile ("");
    }
    3: 5d pop %ebp
    4: c3 ret


    * With my marker implementation (load immediate 0, branch predicted) :

    between 200355 and 200580 cycles total (avg 200400 cycles)
    10.02 cycles per loop (yes, adding the marker increases performance)


    void test(unsigned long arg, unsigned long arg2)
    {
    4d: 55 push %ebp
    4e: 89 e5 mov %esp,%ebp
    50: 83 ec 1c sub $0x1c,%esp
    53: 89 c1 mov %eax,%ecx
    __my_trace_mark(0, kernel_debug_test, NULL, "%d %d %ld %ld", 2, current-
    >pid, arg, arg2);
    55: b0 00 mov $0x0,%al
    57: 84 c0 test %al,%al
    59: 75 02 jne 5d <test+0x10>
    }
    5b: c9 leave
    5c: c3 ret


    * With NOPs :

    avg around 410000 cycles total
    20.5 cycles/loop (slowdown of 2)

    void test(unsigned long arg, unsigned long arg2)
    {
    4d: 55 push %ebp
    4e: 89 e5 mov %esp,%ebp
    50: 83 ec 1c sub $0x1c,%esp
    struct task_struct;

    DECLARE_PER_CPU(struct task_struct *, current_task);
    static __always_inline struct task_struct *get_current(void)
    {
    return x86_read_percpu(current_task);
    53: 64 8b 0d 00 00 00 00 mov %fs:0x0,%ecx
    __my_trace_mark(0, kernel_debug_test, NULL, "%d %d %ld %ld", 2, current-
    >pid, arg, arg2);
    5a: 89 54 24 18 mov %edx,0x18(%esp)
    5e: 89 44 24 14 mov %eax,0x14(%esp)
    62: 8b 81 c4 00 00 00 mov 0xc4(%ecx),%eax
    68: 89 44 24 10 mov %eax,0x10(%esp)
    6c: c7 44 24 0c 02 00 00 movl $0x2,0xc(%esp)
    73: 00
    74: c7 44 24 08 0e 00 00 movl $0xe,0x8(%esp)
    7b: 00
    7c: c7 44 24 04 00 00 00 movl $0x0,0x4(%esp)
    83: 00
    84: c7 04 24 00 00 00 00 movl $0x0,(%esp)
    8b: 90 nop
    8c: 90 nop
    8d: 90 nop
    8e: 90 nop
    8f: 90 nop
    }
    90: c9 leave
    91: c3 ret


    Therefore, because of the cost of stack setup, the load immediate and
    conditionnal branch seems to be _much_ faster than the NOP alternative.

    Mathieu

    --
    Mathieu Desnoyers
    Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
    OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68


    \
     
     \ /
      Last update: 2007-12-08 20:07    [W:0.029 / U:64.916 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site