From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752545AbcBOU05 (ORCPT ); Mon, 15 Feb 2016 15:26:57 -0500 Received: from mailscanner02.zoner.fi ([84.34.166.11]:24980 "EHLO mailscanner02.zoner.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752413AbcBOU0z (ORCPT ); Mon, 15 Feb 2016 15:26:55 -0500 Date: Mon, 15 Feb 2016 22:26:22 +0200 From: Lasse Collin To: Baoquan He Cc: linux-kernel@vger.kernel.org, hpa@zytor.com, alain@knaff.lu, 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: <20160215222622.7e159519@tukaani.org> In-Reply-To: <20160214133138.GA2552@x1.redhat.com> References: <20160212153407.GA2731@x1.redhat.com> <20160213205729.49789fee@tukaani.org> <20160214133138.GA2552@x1.redhat.com> X-Mailer: Claws Mail 3.13.2 (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-14 Baoquan He wrote: > On 02/13/16 at 08:57pm, Lasse Collin wrote: > > 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. > > Thank you so much, Lasse. You clearly pointed out my confusion. > Yeah, I didn't understand it well. Your description for xz in > lib/decompress_unxz.c is very helpful. The 64K is the maximum payload > in one chunk. Adding this 64K is to avoid the worst case that very > small payload can reprsent a 64K uncompressed output data. With my > understanding it could be a chunk which contains complete duplicate > content. like all "0" or other stuff? Yes, like all zeros. I wrote another explanation just in case it helps: In-place decompression puts the compressed data at the end of the buffer and decompresses it to the beginning of the buffer: F = free memory K = uncompressed kernel C = compressed input data Start: FFFFFFFFFFFFFFCCCCCCCC Decompressing: KKKKKKKKKKFFFFFFFFCCCC Finished: KKKKKKKKKKKKKKKKKKKKFF The free memory (FF) at the end is the safety margin. In the worst case the beginning of the uncompressed data compresses to almost nothing (like all zeros do), and the end of the data is incompressible. In the beginning the write position of the decompressor advances quickly while the read position moves very little, and thus the write position quickly approaches the read position: Start: FFFFFFFFFFFFFFCCCCCCCC Decompressing: KKKKKKKKKKKKKKFCCCCCCC Finished: KKKKKKKKKKKKKKKKKKKKFF The safety margin ensures that the write position can never overtake the read position. -- Lasse Collin | IRC: Larhzu @ IRCnet & Freenode