lkml.org 
[lkml]   [2008]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] systemtap: begin the process of using proper kernel APIs (part1: use kprobe symbol_name/offset instead of address)

    > 1) stap ought to use the kernel's infrastructure and not re-implement
    > its own.
    >
    > 2) if the kernel's infrastructure doesn't meet requirements, improve
    > it.

    No argument on either of those. Right now the kernel infrastructure
    is only comparable to what systemtap overs at very high overhead
    costs (see below)

    > But while the x86 might not be perfect, its fairly ok these days. Its
    > not the utter piece of shite x86_64 had for a long time

    Not sure what you're referring to with this. AFAIK the x86-64 unwinder
    for a normal frame pointer less kernel was not any worse (or better)
    than a i386 kernel without frame pointers.

    - today's traces
    > mostly make sense.

    If you enable frame pointers? Making your complete kernel slower?
    Generating much worse code on i386 by wasting >20% of its available
    registers? Getting pipeline stalls on each function call/exit on many CPUs?

    Right now unfortunately there are a few rogue CONFIGs who select that
    so more and more kernels have, but I found that always distateful because
    enabling frame pointers has such a large impact on all kernel code, especially
    on the register starved i386.

    I still think the right solution eventually is to have a dwarf2 unwinder
    by default for i386/x86-64 and get rid of all these nasty "select
    FRAME_POINTER"s which have unfortunately sneaked in.

    -Andi



    \
     
     \ /
      Last update: 2008-07-18 12:33    [W:0.021 / U:0.244 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site