Re: Possible Bootloader Optimization in inflate (get rid of unnecessary 32k Window)

[Coywolf Qi Hunt <coywolf@gmail.com>]

2005/12/22, Axel Kittenberger <axel.kernel@kittenberger.net>:
> Hello, Whom do I talk to about acceptance of Patches in the Bootloader?
>
> I have seen, and coded once some time ago for priv. uses, do infalte the
> gziped linux kernel at boottime in "arch/i386/boot/compressed/misc.c" and "
> windowlib/inflate.c" the deflation algorthimn uses a 32k backtrack window.
> Whenever it is full, it copies it .... into the memory.
>
> While this window makes a lot of sense in an userspace application like
> gunzip, it does not make a lot sense in the bootloader. As userspace
> application the window is flushed to a file when full. The bootloader
> "flushes" it to memory (copies it in memory). That 1 time copy of the whole
> kernel can be optimized away, since we do not keep track of a window since
> the inflater can read what it has written right in the computer memory, while
> it unpacks the kernel.
>
> What would the optimization be worth?
> * A faster uncompressing of the kernel, since a total 1-time memcopy of the
> whole kernel is been optimized away.
> * I'm not sure about the size, the memory or disk footprint. If the 32k static
> (!) memory array in compressed/misc.c, I don't know if it safes 32k running
> memory, or 32k on-disk size. Since I don't know the indepth working of these.

Neither for saving running memory (discarded), nor on-disk size
(window[WSIZE] resides in BSS).

>
> Before I code this again (I know that this optimization has worked with a 2.4

I think 2.6 didn't change much in this field.

> kernel), I want to ask, would such patch be accepted? now or once ever? who
> should I forward this?

"H. Peter Anvin" <hpa@zytor.com>, and akpm, and even Linus. I'd like
to see your patch. It would be instructive.


-- Coywolf