Messages in this thread |  | | | Date | Mon, 05 Jan 2009 11:36:12 -0800 | | From | "H. Peter Anvin" <> | | Subject | Re: tip: bzip2/lzma now in tip:x86/setup-lzma |
| |
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
|  |