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: Andrew Morton <akpm@osdl.org>,
	viro@parcelfarce.linux.theplanet.co.uk, mpm@selenic.com,
	linux-kernel@vger.kernel.org, bcasavan@sgi.com
Subject: Re: [PATCH] kallsyms data size reduction / lookup speedup
Date: Mon, 30 Aug 2004 19:38:07 +0100	[thread overview]
Message-ID: <4133740F.6090505@grupopie.com> (raw)
In-Reply-To: <20040830182141.GB8990@mars.ravnborg.org>

Sam Ravnborg wrote:
> On Thu, Aug 26, 2004 at 11:26:33AM +0100, Paulo Marques wrote:
> 
>>If there is a way to know at compile time the exported symbols, then 
>>scripts/kallsyms might generate a bitmap along with all the other data 
>>it generates so that checking is_exported would become O(1).
> 
> 
> If there exist a symbol named __ksymtab_{symbol} then you know it is exported.

Thanks for the sugestion.

I already looked at EXPORT_SYMBOL in module.h and reached the same 
conclusion, and wrote a patch that did just that.

The problem with that patch was that symbols exported with 
EXPORT_SYMBOL_GPL would show up as exported whereas in the previous 
version they didn't :(

I asked Rusty Russell in private if the old behaviour was the desired 
behaviour or if it would be better to uppercase the symbols that are 
uppercased in System.map (i.e. exported vs public), and he replied that 
the old behaviour was done on purpose and should be kept (at least that 
is what I understood, not being a native speaker and all).

So I'm writting a new version right now that checks that the 
__ksymtab_{symbol} is on the __ksymtab section and not on the 
__ksymtab_gpl section to keep the old behaviour.

Anyway, the patch really speeds up a "time cat /proc/kallsyms" from 
0.25s to 0.00s (I really need to do my own benchmark. "time" doesn't 
have enough resolution :)

I'll probably post it tonight.

-- 
Paulo Marques - www.grupopie.com

To err is human, but to really foul things up requires a computer.
Farmers' Almanac, 1978

  reply	other threads:[~2004-08-30 18:43 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 [this message]
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
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=4133740F.6090505@grupopie.com \
    --to=pmarques@grupopie.com \
    --cc=akpm@osdl.org \
    --cc=bcasavan@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=sam@ravnborg.org \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /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