lkml.org 
[lkml]   [2004]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] Latency Tracer, voluntary-preempt-2.6.8-rc4-O6
Keith Owens wrote:
> On Tue, 17 Aug 2004 13:14:32 +0100,
> Paulo Marques <pmarques@grupopie.com> wrote:
>
>>Keith Owens wrote:
>>
>>>On Sat, 14 Aug 2004 05:50:50 +0100,
>>>Paulo Marques <pmarques@grupopie.com> 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@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.071 / U:0.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site