2004-09-01 05:28:37

by Rusty Russell

[permalink] [raw]
Subject: Re: [PATCH] kallsyms: speed up /proc/kallsyms

On Wed, 2004-09-01 at 06:26, Paulo Marques wrote:
> This patch implements the "is_exported" bit in the kallsyms_names
> compressed stream, so that a "cat /proc/kallsyms" doesn't call
> is_exported on every iteration.

Prefer the patch split into "comments", "inconsistent kallsyms data fix"
and "speedup". I also prefer using a whole letter over a single bit:
this allows archs which have wierd nm letters to express them, and
instead of case indicating what symbols are exported, we get the real
correct results.

Thanks,
Rusty.
--
Anyone who quotes me in their signature is an idiot -- Rusty Russell


2004-09-01 11:17:34

by Paulo Marques

[permalink] [raw]
Subject: Re: [PATCH] kallsyms: speed up /proc/kallsyms

Rusty Russell wrote:
> On Wed, 2004-09-01 at 06:26, Paulo Marques wrote:
>
>>This patch implements the "is_exported" bit in the kallsyms_names
>>compressed stream, so that a "cat /proc/kallsyms" doesn't call
>>is_exported on every iteration.
>
>
> Prefer the patch split into "comments", "inconsistent kallsyms data fix"
> and "speedup". I also prefer using a whole letter over a single bit:
> this allows archs which have wierd nm letters to express them, and
> instead of case indicating what symbols are exported, we get the real
> correct results.

I'm still new to this :(

I'll send more fine-grained patches next time, grouped by issue addressed.

The single bit approach was meant to keep the current behavior, because
that is what I thought you wanted:

> The current code is simple. We could reserve the first letter in
> kallsyms_names for the type letter from System.map. The current upcase
> semantics are deliberately distorted to be more kernel-relevant (ie.
> exported are upper case) but simplistic.
>
> That's how I'd recommend "fixing" it.

I read this as: "we could have used the first letter in each symbol for
the type letter from System.map, but we deliberately distorted the
current semantics to be more kernel-relevant."

Since we are on different time zones, we only get to send an email a
day, so asking for confirmation and waiting for the reply would take a
long time... :(

Anyway, I'm assuming now that what we really want is the same type chars
that appear on the System.map file. If compiled with KALLSYMS_ALL, the
/proc/kallsyms file would be an almost exact copy of System.map.

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.

--
Paulo Marques - http://www.grupopie.com

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

2004-09-01 19:25:49

by Sam Ravnborg

[permalink] [raw]
Subject: Re: [PATCH] kallsyms: speed up /proc/kallsyms

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

2004-09-01 19:47:33

by Paulo Marques

[permalink] [raw]
Subject: Re: [PATCH] kallsyms: speed up /proc/kallsyms

Sam Ravnborg wrote:
> ...
>
> 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.

I'd be glad to do this, but AFAICT the patch already entered the mm
tree, so I think that splitting it now, or sending it through a
different path would probably add to the confusion I already
managed to create :(

Implementing the "type char" should be a single patch on top of this
one, though. I'll be sure to CC you when I post it (probably today).

Thanks,

--
Paulo Marques - http://www.grupopie.com

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

2004-09-01 19:53:49

by Sam Ravnborg

[permalink] [raw]
Subject: Re: [PATCH] kallsyms: speed up /proc/kallsyms

On Wed, Sep 01, 2004 at 08:44:20PM +0100, Paulo Marques wrote:
> Sam Ravnborg wrote:
> >...
> >
> >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.
>
> I'd be glad to do this, but AFAICT the patch already entered the mm
> tree, so I think that splitting it now, or sending it through a
> different path would probably add to the confusion I already
> managed to create :(

I prefer the split-up Rusty requested.
It will then enter -mm via my queue - but as three logical separated
patches. This is much better when looking into this later.

Andrew will just back-out your previous patch and mark it as 'merged'.

Sam

2004-09-02 12:06:28

by Paulo Marques

[permalink] [raw]
Subject: Re: [PATCH] kallsyms: speed up /proc/kallsyms

Sam Ravnborg wrote:
> On Wed, Sep 01, 2004 at 08:44:20PM +0100, Paulo Marques wrote:
>
>>Sam Ravnborg wrote:
>>
>>>...
>>>
>>>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.
>>
>>I'd be glad to do this, but AFAICT the patch already entered the mm
>>tree, so I think that splitting it now, or sending it through a
>>different path would probably add to the confusion I already
>>managed to create :(
>
>
> I prefer the split-up Rusty requested.
> It will then enter -mm via my queue - but as three logical separated
> patches. This is much better when looking into this later.
>
> Andrew will just back-out your previous patch and mark it as 'merged'.

Ok, I'll send you the 3 patches then, no problem.

However, the third patch will already be the "type char"
implementation instead of the "is-exported" bit patch.

All 3 patches will be against 2.6.9-rc1-mm2. I'm just saying
this to make sure I understood correctly what I'm supposed to
do.

Anyway, I did some tests with the "type char" included in the
compressed stream.

The original data: 13743 symbols ~240kB uncompressed data

Compressed:
without type char: 126292 bytes
with type char inserted:
after compression 140035 bytes
before compression 137073 bytes
before compression, lower case 134222 bytes

The last option in this table is to keep the extra bit to say
"the type for this symbol is upper case" and place the type
always in lowercase, to improve compression.

The gain with the lower case doesn't seem to make up for the
_ugliness_ of the method. Keeping an extra bit together with
the length of the symbol, assuming that the symbol length
will never be more than 127, is not pretty at all and forces
the decompression code to have more "special cases".

Inserting just the type char before compressing seems to be
the most cleaner approach.

Note that this is a defconfig setup without the KALLSYMS_ALL
config option. With KALLSYMS_ALL, the compressed stream size
goes to about 300kb and the gains should grow proportionally.
(this reminds me, I should include a patch to change the
help description that says that KALLSYMS_ALL adds about
300kb to the kernel image to say that it adds about 200kb)

I'll try to build all this tonight, and send the new version.

If you don't agree with the "type char" approach that seems
the best to me, please say so now, or forever hold your
peace :)

--
Paulo Marques - http://www.grupopie.com

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

2004-09-02 22:19:52

by Sam Ravnborg

[permalink] [raw]
Subject: Re: [PATCH] kallsyms: speed up /proc/kallsyms

On Thu, Sep 02, 2004 at 01:05:18PM +0100, Paulo Marques wrote:

> All 3 patches will be against 2.6.9-rc1-mm2. I'm just saying
> this to make sure I understood correctly what I'm supposed to
> do.

Preferable on top of Linus - latest.

Sam

2004-09-03 01:28:36

by Paulo Marques

[permalink] [raw]
Subject: Re: [PATCH] kallsyms: speed up /proc/kallsyms

Quoting Sam Ravnborg <[email protected]>:

> On Thu, Sep 02, 2004 at 01:05:18PM +0100, Paulo Marques wrote:
>
> > All 3 patches will be against 2.6.9-rc1-mm2. I'm just saying
> > this to make sure I understood correctly what I'm supposed to
> > do.
>
> Preferable on top of Linus - latest.

I was preparing to do just that, but bumped into a simple problem.

If I patch against Linus tree, then the 3 patches suggested by
Rusty Russell make no sense, because the Linus tree still has stem
compression. So there is no inconsistency bug and there are no
comments to add, there is only a single patch to go from stem
compression to the new compression scheme.

It does not sound so bad to have just one patch that appears at
2.6.9-rc2 that says "change kallsyms compression scheme", so I
have no problem producing this patch.

I'm now holding on to avoid start sending patches against
different trees and make a total mess :(


2004-09-03 01:43:44

by Andrew Morton

[permalink] [raw]
Subject: Re: [PATCH] kallsyms: speed up /proc/kallsyms

"" <[email protected]> wrote:
>
> Quoting Sam Ravnborg <[email protected]>:
>
> > On Thu, Sep 02, 2004 at 01:05:18PM +0100, Paulo Marques wrote:
> >
> > > All 3 patches will be against 2.6.9-rc1-mm2. I'm just saying
> > > this to make sure I understood correctly what I'm supposed to
> > > do.
> >
> > Preferable on top of Linus - latest.
>
> I was preparing to do just that, but bumped into a simple problem.
>
> If I patch against Linus tree, then the 3 patches suggested by
> Rusty Russell make no sense, because the Linus tree still has stem
> compression. So there is no inconsistency bug and there are no
> comments to add, there is only a single patch to go from stem
> compression to the new compression scheme.
>
> It does not sound so bad to have just one patch that appears at
> 2.6.9-rc2 that says "change kallsyms compression scheme", so I
> have no problem producing this patch.
>
> I'm now holding on to avoid start sending patches against
> different trees and make a total mess :(

In that case please prepare diffs against -mm. I've dropped a
snapshot patch against 2.6.9-rc1 at
http://www.zip.com.au/~akpm/linux/patches/stuff/x.bz2

2004-09-03 03:08:30

by Paulo Marques

[permalink] [raw]
Subject: [PATCH] kallsyms: correct type char in /proc/kallsyms

--- linux-2.6.9-rc1-mmsnap/kernel/kallsyms.c 2004-09-03 02:59:57.000000000 +0100
+++ linux-2.6.9-rc1-kall/kernel/kallsyms.c 2004-09-03 02:28:01.000000000 +0100
@@ -51,17 +51,16 @@ static inline int is_kernel_text(unsigne
given the offset to where the symbol is in the compressed stream */
static unsigned int kallsyms_expand_symbol(unsigned int off, char *result)
{
- int len;
+ int len, skipped_first = 0;
u8 *tptr, *data;

- /* get the compressed symbol length from the first symbol byte,
- * masking out the "is_exported" bit */
+ /* get the compressed symbol length from the first symbol byte */
data = &kallsyms_names[off];
- len = (*data) & 0x7F;
+ len = *data;
data++;

/* update the offset to return the offset for the next symbol on
- the compressed stream */
+ * the compressed stream */
off += len + 1;

/* for every byte on the compressed symbol data, copy the table
@@ -72,8 +71,11 @@ static unsigned int kallsyms_expand_symb
len--;

while (*tptr) {
- *result = *tptr;
- result++;
+ if(skipped_first) {
+ *result = *tptr;
+ result++;
+ } else
+ skipped_first = 1;
tptr++;
}
}
@@ -84,24 +86,33 @@ static unsigned int kallsyms_expand_symb
return off;
}

+/* get symbol type information. This is encoded as a single char at the
+ * begining of the symbol name */
+static char kallsyms_get_symbol_type(unsigned int off)
+{
+ /* get just the first code, look it up in the token table, and return the
+ * first char from this token */
+ return kallsyms_token_table[ kallsyms_token_index[ kallsyms_names[off+1] ] ];
+}
+
+
/* find the offset on the compressed stream given and index in the
- kallsyms array */
+ * kallsyms array */
static unsigned int get_symbol_offset(unsigned long pos)
{
u8 *name;
int i;

- /* use the closest marker we have. We have markers every
- 256 positions, so that should be close enough */
+ /* use the closest marker we have. We have markers every 256 positions,
+ * so that should be close enough */
name = &kallsyms_names[ kallsyms_markers[pos>>8] ];

- /* sequentially scan all the symbols up to the point we're
- searching for. Every symbol is stored in a
- [bit 7: is_exported | bits 6..0: <len>][<len> bytes of data]
- format, so we just need to add the len to the current
- pointer for every symbol we wish to skip */
+ /* sequentially scan all the symbols up to the point we're searching for.
+ * Every symbol is stored in a [<len>][<len> bytes of data] format, so we
+ * just need to add the len to the current pointer for every symbol we
+ * wish to skip */
for(i = 0; i < (pos&0xFF); i++)
- name = name + ((*name) & 0x7F) + 1;
+ name = name + (*name) + 1;

return name - kallsyms_names;
}
@@ -243,15 +254,8 @@ static unsigned long get_ksymbol_core(st

iter->owner = NULL;
iter->value = kallsyms_addresses[iter->pos];
-
- if (is_kernel_text(iter->value) || is_kernel_inittext(iter->value))
- iter->type = 't';
- else
- iter->type = 'd';
-
- /* check the "is_exported" bit on the compressed stream */
- if (kallsyms_names[off] & 0x80)
- iter->type += 'A' - 'a';
+
+ iter->type = kallsyms_get_symbol_type(off);

off = kallsyms_expand_symbol(off, iter->name);

--- linux-2.6.9-rc1-mmsnap/scripts/kallsyms.c 2004-09-03 02:59:57.000000000 +0100
+++ linux-2.6.9-rc1-kall/scripts/kallsyms.c 2004-09-03 02:35:25.000000000 +0100
@@ -55,7 +55,6 @@
/* flags to mark symbols */
#define SYM_FLAG_VALID 1
#define SYM_FLAG_SAMPLED 2
-#define SYM_FLAG_EXPORTED 4

struct sym_entry {
unsigned long long addr;
@@ -68,12 +67,9 @@ struct sym_entry {

static struct sym_entry *table;
static int size, cnt;
-static unsigned long long _stext, _etext, _sinittext, _einittext, _start_ksymtab, _stop_ksymtab;
+static unsigned long long _stext, _etext, _sinittext, _einittext;
static int all_symbols = 0;

-/* aray of pointers into the symbol table sorted by name */
-static struct sym_entry **sorted_table;
-
struct token {
unsigned char data[MAX_TOK_SIZE];
unsigned char len;
@@ -125,45 +121,56 @@ read_symbol(FILE *in, struct sym_entry *
_sinittext = s->addr;
else if (strcmp(str, "_einittext") == 0)
_einittext = s->addr;
- else if (strcmp(str, "__start___ksymtab") == 0)
- _start_ksymtab = s->addr;
- else if (strcmp(str, "__stop___ksymtab") == 0)
- _stop_ksymtab = s->addr;
else if (toupper(s->type) == 'A' || toupper(s->type) == 'U')
return -1;

- s->sym = strdup(str);
- s->len = strlen(str);
+ /* include the type field in the symbol name, so that it gets
+ * compressed together */
+ s->len = strlen(str) + 1;
+ s->sym = (char *) malloc(s->len + 1);
+ strcpy(s->sym + 1, str);
+ s->sym[0] = s->type;
+
return 0;
}

static int
symbol_valid(struct sym_entry *s)
{
+ /* Symbols which vary between passes. Passes 1 and 2 must have
+ * identical symbol lists. The kallsyms_* symbols below are only added
+ * after pass 1, they would be included in pass 2 when --all-symbols is
+ * specified so exclude them to get a stable symbol list.
+ */
+ static char *special_symbols[] = {
+ "kallsyms_addresses",
+ "kallsyms_num_syms",
+ "kallsyms_names",
+ "kallsyms_markers",
+ "kallsyms_token_table",
+ "kallsyms_token_index",
+
+ /* Exclude linker generated symbols which vary between passes */
+ "_SDA_BASE_", /* ppc */
+ "_SDA2_BASE_", /* ppc */
+ NULL };
+ int i;
+
+ /* if --all-symbols is not specified, then symbols outside the text
+ * and inittext sections are discarded */
if (!all_symbols) {
if ((s->addr < _stext || s->addr > _etext)
&& (s->addr < _sinittext || s->addr > _einittext))
return 0;
}

- /* Exclude symbols which vary between passes. Passes 1 and 2 must have
- * identical symbol lists. The kallsyms_* symbols below are only added
- * after pass 1, they would be included in pass 2 when --all-symbols is
- * specified so exclude them to get a stable symbol list.
- */
- if (strstr(s->sym, "_compiled.") ||
- strcmp(s->sym, "kallsyms_addresses") == 0 ||
- strcmp(s->sym, "kallsyms_num_syms") == 0 ||
- strcmp(s->sym, "kallsyms_names") == 0 ||
- strcmp(s->sym, "kallsyms_markers") == 0 ||
- strcmp(s->sym, "kallsyms_token_table") == 0 ||
- strcmp(s->sym, "kallsyms_token_index") == 0)
+ /* Exclude symbols which vary between passes. */
+ if (strstr(s->sym + 1, "_compiled."))
return 0;

- /* Exclude linker generated symbols which vary between passes */
- if (strcmp(s->sym, "_SDA_BASE_") == 0 || /* ppc */
- strcmp(s->sym, "_SDA2_BASE_") == 0) /* ppc */
- return 0;
+ for (i = 0; special_symbols[i]; i++)
+ if( strcmp(s->sym + 1, special_symbols[i]) == 0 )
+ return 0;

return 1;
}
@@ -267,9 +274,7 @@ write_src(void)
if ((valid & 0xFF) == 0)
markers[valid >> 8] = off;

- k = table[i].len;
- if (table[i].flags & SYM_FLAG_EXPORTED) k |= 0x80;
- printf("\t.byte 0x%02x", k);
+ printf("\t.byte 0x%02x", table[i].len);
for (k = 0; k < table[i].len; k++)
printf(", 0x%02x", table[i].sym[k]);
printf("\n");
@@ -463,47 +468,11 @@ static void forget_symbol(unsigned char
forget_token(symbol + i, len - i);
}

-static int symbol_sort(const void *a, const void *b)
-{
- return strcmp( (*((struct sym_entry **) a))->sym,
- (*((struct sym_entry **) b))->sym );
-}
-
-
-/* find out if a symbol is exported. Exported symbols have a corresponding
- * __ksymtab_<symbol> entry and their addresses are between __start___ksymtab
- * and __stop___ksymtab */
-static int is_exported(char *name)
-{
- struct sym_entry key, *ksym, **result;
- char buf[KSYM_NAME_LEN+32];
-
- sprintf(buf, "__ksymtab_%s", name);
- key.sym = buf;
-
- ksym = &key;
- result = bsearch(&ksym, sorted_table, cnt,
- sizeof(struct sym_entry *), symbol_sort);
-
- if(!result) return 0;
-
- ksym = *result;
-
- return ((ksym->addr >= _start_ksymtab) && (ksym->addr < _stop_ksymtab));
-}
-
/* set all the symbol flags and do the initial token count */
static void build_initial_tok_table(void)
{
int i, use_it, valid;

- /* build a sorted symbol pointer array so that searching a particular
- * symbol is faster */
- sorted_table = (struct sym_entry **) malloc(sizeof(struct sym_entry *) * cnt);
- for (i = 0; i < cnt; i++)
- sorted_table[i] = &table[i];
- qsort(sorted_table, cnt, sizeof(struct sym_entry *), symbol_sort);
-
valid = 0;
for (i = 0; i < cnt; i++) {
table[i].flags = 0;
@@ -515,6 +484,10 @@ static void build_initial_tok_table(void

use_it = 0;
for (i = 0; i < cnt; i++) {
+
+ /* subsample the available symbols. This method is almost like
+ * a Bresenham's algorithm to get uniformly distributed samples
+ * across the symbol table */
if (table[i].flags & SYM_FLAG_VALID) {

use_it += WORKING_SET;
@@ -523,9 +496,6 @@ static void build_initial_tok_table(void
table[i].flags |= SYM_FLAG_SAMPLED;
use_it -= valid;
}
-
- if( is_exported(table[i].sym) )
- table[i].flags |= SYM_FLAG_EXPORTED;
}
if (table[i].flags & SYM_FLAG_SAMPLED)
learn_symbol(table[i].sym, table[i].len);


Attachments:
patch (8.83 kB)