From: Paulo Marques <pmarques@grupopie.com>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: linux-kernel@vger.kernel.org, bcasavan@sgi.com
Subject: Re: [PATCH] kallsyms data size reduction / lookup speedup
Date: Thu, 26 Aug 2004 01:27:39 +0100 [thread overview]
Message-ID: <412D2E7B.7000202@grupopie.com> (raw)
In-Reply-To: <20040825205113.GA7258@mars.ravnborg.org>
Sam Ravnborg wrote:
> On Wed, Aug 25, 2004 at 05:04:46AM +0100, pmarques@grupopie.com wrote:
>
>>This patch is an improvement over my first kallsyms speedup patch posted about 2
>>weeks ago.
>
>
> My origianl comment still hold.
> Decoupling the compression and decompression part is not good.
> Better keep them close to each other.
In this case the decompression step is so simple that I don't think this
is really a problem.
At least the source code is close to each other.
> Why not put all symbols in an __init section, compress them during kernel boot
> and then the original section get discarded.
In that case we should definitely change the algorithm as the
compression step is quite hard. It was designed to run only at compile
time, so code size / speed trade-offs would all tend to increase the
code size, and even as it is it would slow down the boot sequence.
Anyway, even if the code and data is discarded as they would be in an
__init section, the compression code would still be in the kernel image.
This can reduce the areas of application of this code (boot from a
floppy, embedded systems, etc.)
It _seems_ silly to have code in there that works over the same data
every time it boots and produces the exact same result. I must say
however that I realize that I'm a newcomer and I might not be seeing the
hole picture. So, if it is the general consensus that this is the way to
go, then fine by me :)
> After a quick browse of the code.
> - Use spaces around '=' etc.
I'm really sorry about this. I've tried to not let these escape, but
some of them (many of them, in fact) did. I promise I'll be more
thorough next time.
--
Paulo Marques - www.grupopie.com
next prev parent reply other threads:[~2004-08-26 0:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-25 4:04 [PATCH] kallsyms data size reduction / lookup speedup pmarques
2004-08-25 17:39 ` Matt Mackall
2004-08-25 18:46 ` Paulo Marques
2004-08-25 18:58 ` Matt Mackall
2004-08-25 19:09 ` Paulo Marques
2004-08-25 19:29 ` viro
2004-08-25 23:40 ` Paulo Marques
2004-08-25 23:43 ` viro
2004-08-26 9:59 ` Andrew Morton
2004-08-26 10:26 ` Paulo Marques
2004-08-30 18:21 ` Sam Ravnborg
2004-08-30 18:38 ` Paulo Marques
2004-08-25 21:12 ` Matt Mackall
2004-08-25 23:50 ` Paulo Marques
2004-08-25 20:51 ` Sam Ravnborg
2004-08-25 21:25 ` Randy.Dunlap
2004-08-26 0:27 ` Paulo Marques [this message]
2004-08-26 11:01 ` Paulo Marques
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=412D2E7B.7000202@grupopie.com \
--to=pmarques@grupopie.com \
--cc=bcasavan@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox