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    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site