Re: [patch] Latency Tracer, voluntary-preempt-2.6.8-rc4-O6

[Paulo Marques]

Keith Owens wrote:
> On Tue, 17 Aug 2004 13:14:32 +0100, 
> Paulo Marques <pmarques@xxxxxxxxxxxx> wrote:
>
> > Keith Owens wrote:
> >
> > > On Sat, 14 Aug 2004 05:50:50 +0100, 
> > > Paulo Marques <pmarques@xxxxxxxxxxxx> wrote:
> > >
> > >
> > > > Well, I found some time and decided to give it a go :)
> > >
> > >
> > > This patch regresses some recent changes to kallsyms which handle
> > > aliased symbols, IOW symbols with the same address.  The speed up is
> > > very good, but it has two problems with repeated addresses.
> >
> > Hi,
> >
> > I've been messing with scripts/kallsyms.c to try to follow Andi Kleen's 
> > suggestion of calculating the markers at compile time. This would make 
> > the code in kernel/kallsyms.c much simpler.
> >
> > In the process I could get rid of the aliased symbols at compile time 
> > also. There are only 2 places where they might matter:
> >
> > - the kallsyms_lookup_name function. GREP'ing through the code shows 
> > that this function is only used in arch/ppc64/xmon/xmon.c. Does xmon 
> > need to know about aliased symbols?
>
>
> kdb uses aliased symbols as well.  The user can enter any kernel symbol
> name and have it converted to an address.

Ok, I'll leave them alone, then.

Just another quick question: is kallsyms_names only used by the 
functions in kallsyms.c and everyone else simply uses those functions, 
or are there direct users of kallsyms_names?

This is because another thing I was pondering was to change the stem 
compression scheme into a different one, changing all the stuff in 
kallsyms.c accordingly. If there are direct users of kallsyms_names, 
this would break them. There are none in the vanilla kernel as far as I 
can grep, but there might be outside (like in kdb).

I've done some tests with a different scheme and my uncompressed 170kb 
symbol table goes to about 134kb with stem compression and to about 90kb 
with the new scheme. This is not usable right now because compression 
still takes a long time (although the decompression inside 
kernel/kallsyms.c is even simpler than it is now). I'm now trying to 
speed up compression.

As always, comments will be greatly appreciated :)

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