From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751316AbcBMTEw (ORCPT ); Sat, 13 Feb 2016 14:04:52 -0500 Received: from mailscanner02.zoner.fi ([84.34.166.11]:49223 "EHLO mailscanner02.zoner.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750993AbcBMTEu (ORCPT ); Sat, 13 Feb 2016 14:04:50 -0500 X-Greylist: delayed 411 seconds by postgrey-1.27 at vger.kernel.org; Sat, 13 Feb 2016 14:04:50 EST Date: Sat, 13 Feb 2016 20:57:29 +0200 From: Lasse Collin To: Baoquan He Cc: linux-kernel@vger.kernel.org, hpa@zytor.com, alain@knaff.lu, albin.tonnerre@free-electrons.com, phillip@lougher.demon.co.uk, akpm@linux-foundation.org, keescook@chromium.org, bp@alien8.de, vgoyal@redhat.com Subject: Re: About support XZ-compressed kernel on x86 Message-ID: <20160213205729.49789fee@tukaani.org> In-Reply-To: <20160212153407.GA2731@x1.redhat.com> References: <20160212153407.GA2731@x1.redhat.com> X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Clean mail though you should still use an Antivirus Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016-02-12 Baoquan He wrote: > Now I have a question about the commit from you: > > commit 303148045aac34b70db722a54e5ad94a3a6625c6 > Author: Lasse Collin > 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