Re: [PATCH] Sort kallsyms in name order: kernel shrinks by 30k
From: Rusty Russell
Date: Tue May 11 2004 - 18:22:03 EST
On Tue, 2004-05-11 at 18:08, Andi Kleen wrote:
> On Tue, May 11, 2004 at 03:08:55PM +1000, Rusty Russell wrote:
> > Admittedly, anyone who sets CONFIG_KALLSYMS doesn't care about space,
> > it's a fairly trivial change.
> As long as nobody does binary search it's good. Wonder why I did not
> have this idea already with the original stem compression change ;-)
ISTR that someone (I thought you) mentioned doing this before.
In general this code was considered non-speed-critical, but Keith points
out its use in wchan. A simple cache might make more sense there,
A binary search as stands doesn't help much because we still need to
iterate through the names. We could do "address, nameindex" pairs, but
with stem compression we need to at least wade back some way to decode
I have a 30-line static huffman decoder (from the IDE mini-oopser) which
we could use instead of stem compression, which we could combine with
"address, bitoffset" pairs which would be about 20k smaller and faster
than the current approach, but is it worth the trouble?
Anyone who quotes me in their signature is an idiot -- Rusty Russell
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/