On 2016-02-12 Baoquan He wrote: > Now I have a question about the commit from you: > > commit 303148045aac34b70db722a54e5ad94a3a6625c6 > Author: Lasse Collin <lasse.col...@tukaani.org> > Date: Wed Jan 12 17:01:24 2011 -0800 > > x86: support XZ-compressed kernel > > > In this commit for adding support of XZ-compressed kernel on x86, you > add extra 32K to the extract_offset. In commit log you said this is > because "The XZ decompressor needs around 30 KiB of heap, so the heap > size is increased to 32 KiB on both x86-32 and x86-64." With my > understanding decompression is done in decompression stage and it uses > boot_heap in arch/x86/boot/compressed/head_64.S, and boot_heap is > assigned to free_mem_ptr which is used for decompression heap malloc. > During this decompressio stage it's still in copied ZO space, why did > you add extra 32K space to extract_offset? If you want to increase > the decompression heap space shouldn't you decrease the > extract_offset? Do I misunderstand anything or miss things?
The reason to increase the heap size in arch/x86/include/asm/boot.h is unrelated to the reason why the offset was changed in arch/x86/boot/compressed/mkpiggy.c. The long comment in arch/x86/boot/compressed/misc.c explains the need for the offset for gzip/Deflate. A similar comment in lib/decompress_unxz.c explains it for XZ/LZMA2. Smaller safety-margins can work in practice since the calculated margins are for the worst case. I'm not even sure if such calculations have been done for the other decompressors in Linux. -- Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
