From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932327AbcBPNUb (ORCPT ); Tue, 16 Feb 2016 08:20:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39692 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932131AbcBPNU2 (ORCPT ); Tue, 16 Feb 2016 08:20:28 -0500 Date: Tue, 16 Feb 2016 21:20:20 +0800 From: Baoquan He To: Lasse Collin 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: <20160216132020.GA2517@x1.redhat.com> References: <20160212153407.GA2731@x1.redhat.com> <20160213205729.49789fee@tukaani.org> <20160214133138.GA2552@x1.redhat.com> <20160215222622.7e159519@tukaani.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160215222622.7e159519@tukaani.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/15/16 at 10:26pm, Lasse Collin wrote: > 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: Yes, this is great and very helpful for people who want to understand this details. I want to make some change to improve the readability of the description in boot/compressed/misc.c, do you mind if I put these there? Or you can post a patch to adjust it. Thanks Baoquan > > 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