public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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