Skip to contentSkip to conversation

Results of actual compile printk format compression

DISCUSSION Timothy Miller 2 participants 2 messages Jun 6, 2003 – Jun 7, 2003

lore
Share & tools
lore
#0 lore raw

Just a quick note...

Although my experiments with kernel printk format string compression have reported estimated shrinkage, this is the first time I have been able to compile a whole kernel with the compression filter.

These results come from doing an allyesconfig of 2.5.68 and then weeding out anything that didn't build. One program extracts strings from preprocessor output, a second program determines how the strings will be encoded, and the third makes substitutions during a kernel compile.

The uncompressed compile resulted in a kernel image of 24011892 bytes. The resulting image with format strings compressed is 23904708 bytes which is a shrinkage of 107184 bytes. Subtracting out an estimate of 3K for the dictionary and necessary modifications to printk, that results in a reduction of something like 104112 which is 4% of the original kernel size.

That may not seem like a lot, but if you consider only the printk strings themselves, they are compressed to less than 50% of their original size (counting the dictionary but not printk code mods).

So, I ask... is this a useful savings? Is there any chance anyone would bother to increase their compile time by a factor of 5 in order to shave off 4% or 100k bytes?

(Not to mention that allyesconfig is a very unrealistic scenario.)

#1 lore raw
Quoted 22 lines · Timothy Miller

Just a quick note...

Although my experiments with kernel printk format string compression have reported estimated shrinkage, this is the first time I have been able to compile a whole kernel with the compression filter.

These results come from doing an allyesconfig of 2.5.68 and then weeding out anything that didn't build. One program extracts strings from preprocessor output, a second program determines how the strings will be encoded, and the third makes substitutions during a kernel compile.

The uncompressed compile resulted in a kernel image of 24011892 bytes. The resulting image with format strings compressed is 23904708 bytes which is a shrinkage of 107184 bytes. Subtracting out an estimate of 3K for the dictionary and necessary modifications to printk, that results in a reduction of something like 104112 which is 4% of the original kernel size.

That may not seem like a lot, but if you consider only the printk strings themselves, they are compressed to less than 50% of their original size (counting the dictionary but not printk code mods).

Quoted 5 lines

So, I ask... is this a useful savings? Is there any chance anyone would bother to increase their compile time by a factor of 5 in order to shave off 4% or 100k bytes?

(Not to mention that allyesconfig is a very unrealistic scenario.)

Sincerely, with machines ranging 512MB of memory, 100KB of memory saving is just so little, that factoring kernel compilation by 5 is something I'm not willing to take.

However, it could be useful to include that feature for memory constrained systems, like embedded ones, and allow enabling it at compile/configure time.