Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752953AbdC0NZP (ORCPT ); Mon, 27 Mar 2017 09:25:15 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:34993 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752195AbdC0NZG (ORCPT ); Mon, 27 Mar 2017 09:25:06 -0400 MIME-Version: 1.0 In-Reply-To: <2e97b35f-bb9e-66e4-736d-66313626354e@suse.com> References: <1490273467-97948-1-git-send-email-chao.p.peng@linux.intel.com> <20170323153117.GA6356@tigerII.localdomain> <1490333740.2925.7.camel@linux.intel.com> <20170327075817.bb7wda62fcuvfa4b@linutronix.de> <2e97b35f-bb9e-66e4-736d-66313626354e@suse.com> From: Arnd Bergmann Date: Mon, 27 Mar 2017 15:25:04 +0200 X-Google-Sender-Auth: AbMUpa4p44yHNcdiHM8T0KL8L4Y Message-ID: Subject: Re: [PATCH] x86/boot: Support uncompressed kernel To: Michal Marek Cc: Sebastian Andrzej Siewior , Chao Peng , Sergey Senozhatsky , Yinghai Lu , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , "the arch/x86 maintainers" , Kees Cook , Baoquan He , "H.J. Lu" , Paul Bolle , Masahiro Yamada , Borislav Petkov , Andrew Morton , Petr Mladek , "David S. Miller" , "Paul E. McKenney" , Andy Lutomirski , Thomas Garnier , Nicolas Pitre , Tejun Heo , Daniel Mack , Helge Deller , Rik van Riel , Linux Kernel Mailing List , linux-kbuild Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1023 Lines: 24 On Mon, Mar 27, 2017 at 1:47 PM, Michal Marek wrote: > Dne 27.3.2017 v 09:58 Sebastian Andrzej Siewior napsal(a): >> On 2017-03-24 13:35:40 [+0800], Chao Peng wrote: >>> >>>>>> kernel kernel size time in decompress_kernel >>>>>> compressed (gzip) 3.3M 53ms >>>>>> uncompressed 14M 3ms >>>>> >>> Exactly, LZ4 is the fastest. It takes 16ms to complete the >>> decompression. Still sounds a little longer when compared to >>> uncompressed kernel. >> >> Are we seriously talking here about one-time improvement of 13ms >> boot time? > > If the use case is launching new VM instances continuously, then > compressing the kernel image is about as useful as compressing /bin/bash. I guess the next step would be to use CONFIG_XIP_KERNEL on x86, which requires an uncompressed kernel but has the additional advantage of sharing the read-only sections of the kernel image across virtual machines, resulting in better RAM and cache usage. Arnd