Re: tip: bzip2/lzma now in tip:x86/setup-lzma

H. Peter Anvin
2009-01-05T19:35:59Z

Alain Knaff wrote:
> Exactly the reason why in one of my first versions I wanted to do away
> with that feature.... until you pointed out that it was actually using
> more *memory* when not compressed, because of the way the buffer cache
> works when the initramfs is put into place (it is not freed "as we go",
> but only at the very end, so at one point in time there will be 2 copies
> which will of course be larger when they're both uncompressed).
>
> I'm getting the impression that again, anybody wanting to propose an
> enhancement must solve _all_ pre-existing problems in that area... While
> this certainly leads to better code once a patch does make it, it will
> certainly discourage many.

Yes. That is a deliberate tradeoff in our culture. It's hardly a
secret, either.

> Maybe we can separate both issues, and tackle the initramfs case
> entirely separately (maybe by proving a buffer cache enhancement that
> allows to free initramfs' memory "as we go").

Well, I think the right thing to do at this stage is to simply compress
the initramfs with the preferred compression method (and if no
compression method is provided, with none.) This can be relatively
simply done with a script, I think.

At least that way the whole image is compressed using the preferred
compression format, and since all the relevant compressors have methods
of dealing reasonably with uncompressable chunks we should be okay.

Doing the "free as you go" thing is definitely something I would like to
see, as well as supporting initramfs in high memory. I have looked at
it a few times, however, it is a nontrivial modification and I haven't
personally devoted the time to dealing with it. I really don't think we
want to entangle this issue with the compression patch.

-hpa