All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Paulo Marques <pmarques@grupopie.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>, Matt Mackall <mpm@selenic.com>
Subject: Re: [PATCH] kallsyms: speed up /proc/kallsyms
Date: Wed, 1 Sep 2004 21:27:55 +0200	[thread overview]
Message-ID: <20040901192755.GC7219@mars.ravnborg.org> (raw)
In-Reply-To: <4135AFBE.1000707@grupopie.com>

On Wed, Sep 01, 2004 at 12:17:18PM +0100, Paulo Marques wrote:
 
> So, moving forward...
> 
> A defconfig build produces 13743 symbols with a compressed name stream
> of ~130kB. (it is 240kB uncompressed, for the curious)
> 
> Adding a letter to each symbol would increase this by about 10%.
> 
> We can try 2 different approaches to minimize the impact of this:
> 
>  - have the letter inserted before the compression step. This way, the
>    table of the best tokens may have "tacpi_" instead of "acpi_" and
>    the compression would not suffer as much, except that the symbols
>    started with "Tacpi_" would suffer. Only real tests can show how
>    this would turn out.
> 
>  - build a "sections" table that groups together symbols with the same
>    letter. The table would say symbols that have addresses between
>    X and Y would have letter Z. This can go horribly wrong if there
>    are situations where completely different type letters appear
>    intermixed.
> 
> I think I'll try the first approach first and see how it goes. I'll
> post as soon as I got some numbers.

When you have made the split Rusty requested and implemented
the above could you please send patches to me. I will add them to
my kbuild queue.

Yes - I have acccepted your rationale why to keep the split
of functionality between kallsyms and the kernel.

	Sam

  reply	other threads:[~2004-09-01 19:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-31 20:26 [PATCH] kallsyms: speed up /proc/kallsyms Paulo Marques
2004-09-01  5:24 ` Rusty Russell
2004-09-01 11:17   ` Paulo Marques
2004-09-01 19:27     ` Sam Ravnborg [this message]
2004-09-01 19:44       ` Paulo Marques
2004-09-01 19:51         ` Sam Ravnborg
2004-09-02 12:05           ` Paulo Marques
2004-09-02 22:17             ` Sam Ravnborg
2004-09-03  1:31               ` pmarques
2004-09-03  1:31                 ` Andrew Morton
2004-09-03  2:59                   ` [PATCH] kallsyms: correct type char in /proc/kallsyms Paulo Marques
2004-09-01 11:38 ` [PATCH] kallsyms: speed up /proc/kallsyms 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=20040901192755.GC7219@mars.ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=pmarques@grupopie.com \
    --cc=rusty@rustcorp.com.au \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.