lkml.org 
[lkml]   [2004]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    Date
    From
    SubjectRe: [patch] Latency Tracer, voluntary-preempt-2.6.8-rc4-O6
    On Fri, Aug 13, 2004 at 02:15:02PM +0200, Ingo Molnar wrote:
    >
    > * Andi Kleen <ak@muc.de> wrote:
    >
    > > >> Interesting results. One of the problems is kallsyms_lookup,
    > > >> triggered by the printks:
    > > >
    > > > yeah - kallsyms_lookup does a linear search over thousands of symbols.
    > > > Especially since /proc/latency_trace uses it too it would be worthwile
    > > > to implement some sort of binary searching.
    > >
    > > Or just stick some cond_sched()s in there. It was designed to be slow,
    > > but there are no locking issues.
    >
    > the speedup would be important: even on a 2GHz box reading 10,000 trace
    > entries takes a couple of seconds.

    That's because you're abusing it - it was never designed to process
    that much data.

    With binary search you would need to backward search to find the stem for the
    stem compression. It's probably doable, but would be a bit ugly I guess.

    -Andi
    -
    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: 2005-03-22 14:05    [W:0.021 / U:60.936 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site