Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1607460 > unrolled thread

[PATCH] x86/boot: Support uncompressed kernel

Started byChao Peng <chao.p.peng@linux.intel.com>
First post2017-03-23 14:10 +0100
Last post2017-03-24 09:30 +0100
Articles 9 — 6 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] x86/boot: Support uncompressed kernel Chao Peng <chao.p.peng@linux.intel.com> - 2017-03-23 14:10 +0100
    Re: [PATCH] x86/boot: Support uncompressed kernel Yinghai Lu <yinghai@kernel.org> - 2017-03-23 16:10 +0100
      Re: [PATCH] x86/boot: Support uncompressed kernel Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2017-03-23 16:40 +0100
        Re: [PATCH] x86/boot: Support uncompressed kernel Chao Peng <chao.p.peng@linux.intel.com> - 2017-03-24 06:40 +0100
          Re: [PATCH] x86/boot: Support uncompressed kernel Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2017-03-27 10:10 +0200
            Re: [PATCH] x86/boot: Support uncompressed kernel Chao Peng <chao.p.peng@linux.intel.com> - 2017-03-27 11:30 +0200
            Re: [PATCH] x86/boot: Support uncompressed kernel Michal Marek <mmarek@suse.com> - 2017-03-27 14:00 +0200
              Re: [PATCH] x86/boot: Support uncompressed kernel Arnd Bergmann <arnd@arndb.de> - 2017-03-27 15:30 +0200
    Re: [PATCH] x86/boot: Support uncompressed kernel Michal Marek <mmarek@suse.com> - 2017-03-24 09:30 +0100

#1607460 — [PATCH] x86/boot: Support uncompressed kernel

FromChao Peng <chao.p.peng@linux.intel.com>
Date2017-03-23 14:10 +0100
Subject[PATCH] x86/boot: Support uncompressed kernel
Message-ID<toaF4-2Eh-13@gated-at.bofh.it>
Compressed kernel has its own drawback: uncompressing takes time. Even
though the time is short enough to ignore for most cases but for cases that
time is critical this is still a big number. In our on-going optimization
for kernel boot time, the measured overall kernel boot time is ~90ms while
the uncompressing takes ~50ms with gzip.

The patch adds a 'CONFIG_KERNEL_RAW' configure choice so the built binary
can have no uncompressing at all. The experiment shows:

    kernel               kernel size    time in decompress_kernel
    compressed (gzip)    3.3M           53ms
    uncompressed         14M            3ms

Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
---
 arch/x86/boot/compressed/Makefile |  3 +++
 arch/x86/boot/compressed/misc.c   | 14 ++++++++++++++
 init/Kconfig                      |  7 +++++++
 scripts/Makefile.lib              |  8 ++++++++
 4 files changed, 32 insertions(+)

diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index f9ce75d..fc0e1c0 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -73,6 +73,8 @@ $(obj)/vmlinux.relocs: vmlinux FORCE
 vmlinux.bin.all-y := $(obj)/vmlinux.bin
 vmlinux.bin.all-$(CONFIG_X86_NEED_RELOCS) += $(obj)/vmlinux.relocs
 
+$(obj)/vmlinux.bin.raw: $(vmlinux.bin.all-y) FORCE
+	$(call if_changed,raw)
 $(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE
 	$(call if_changed,gzip)
 $(obj)/vmlinux.bin.bz2: $(vmlinux.bin.all-y) FORCE
@@ -86,6 +88,7 @@ $(obj)/vmlinux.bin.lzo: $(vmlinux.bin.all-y) FORCE
 $(obj)/vmlinux.bin.lz4: $(vmlinux.bin.all-y) FORCE
 	$(call if_changed,lz4)
 
+suffix-$(CONFIG_KERNEL_RAW)	:= raw
 suffix-$(CONFIG_KERNEL_GZIP)	:= gz
 suffix-$(CONFIG_KERNEL_BZIP2)	:= bz2
 suffix-$(CONFIG_KERNEL_LZMA)	:= lzma
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 79dac17..fb3cd43 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -123,6 +123,20 @@ static char *vidmem;
 static int vidport;
 static int lines, cols;
 
+#ifdef CONFIG_KERNEL_RAW
+#include <linux/decompress/mm.h>
+static int __decompress(unsigned char *buf, long len,
+			long (*fill)(void*, unsigned long),
+			long (*flush)(void*, unsigned long),
+			unsigned char *outbuf, long olen,
+			long *pos,
+			void (*error)(char *x))
+{
+	memcpy(outbuf, buf, olen);
+	return 0;
+}
+#endif
+
 #ifdef CONFIG_KERNEL_GZIP
 #include "../../../../lib/decompress_inflate.c"
 #endif
diff --git a/init/Kconfig b/init/Kconfig
index 2232080..1db2ea2 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -137,6 +137,13 @@ choice
 
 	  If in doubt, select 'gzip'
 
+config KERNEL_RAW
+	bool "RAW"
+	help
+	  No compression. It creates much bigger kernel and uses much more
+	  space (disk/memory) than other choices. It can be useful when
+	  decompression speed is the most concern while space is not a problem.
+
 config KERNEL_GZIP
 	bool "Gzip"
 	depends on HAVE_KERNEL_GZIP
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 2edbcad..384128d 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -344,6 +344,14 @@ cmd_lz4 = (cat $(filter-out FORCE,$^) | \
 	lz4c -l -c1 stdin stdout && $(call size_append, $(filter-out FORCE,$^))) > $@ || \
 	(rm -f $@ ; false)
 
+# RAW
+# ---------------------------------------------------------------------------
+quiet_cmd_raw = RAW     $@
+cmd_raw = (cat $(filter-out FORCE,$^) && \
+	$(call size_append, $(filter-out FORCE,$^))) > $@ || \
+	(rm -f $@ ; false)
+
+
 # U-Boot mkimage
 # ---------------------------------------------------------------------------
 
-- 
1.8.3.1

[toc] | [next] | [standalone]


#1607589

FromYinghai Lu <yinghai@kernel.org>
Date2017-03-23 16:10 +0100
Message-ID<tocxd-3SR-53@gated-at.bofh.it>
In reply to#1607460
On Thu, Mar 23, 2017 at 5:51 AM, Chao Peng <chao.p.peng@linux.intel.com> wrote:
> Compressed kernel has its own drawback: uncompressing takes time. Even
> though the time is short enough to ignore for most cases but for cases that
> time is critical this is still a big number. In our on-going optimization
> for kernel boot time, the measured overall kernel boot time is ~90ms while
> the uncompressing takes ~50ms with gzip.
>
> The patch adds a 'CONFIG_KERNEL_RAW' configure choice so the built binary
> can have no uncompressing at all. The experiment shows:
>
>     kernel               kernel size    time in decompress_kernel
>     compressed (gzip)    3.3M           53ms
>     uncompressed         14M            3ms

How about the time difference for bootloader to read kernel from
flash/disk/network to ram?

Thanks

Yinghai

[toc] | [prev] | [next] | [standalone]


#1607631

FromSergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date2017-03-23 16:40 +0100
Message-ID<tod0e-4a5-21@gated-at.bofh.it>
In reply to#1607589
On (03/23/17 08:07), Yinghai Lu wrote:
> On Thu, Mar 23, 2017 at 5:51 AM, Chao Peng <chao.p.peng@linux.intel.com> wrote:
> > Compressed kernel has its own drawback: uncompressing takes time. Even
> > though the time is short enough to ignore for most cases but for cases that
> > time is critical this is still a big number. In our on-going optimization
> > for kernel boot time, the measured overall kernel boot time is ~90ms while
> > the uncompressing takes ~50ms with gzip.
> >
> > The patch adds a 'CONFIG_KERNEL_RAW' configure choice so the built binary
> > can have no uncompressing at all. The experiment shows:
> >
> >     kernel               kernel size    time in decompress_kernel
> >     compressed (gzip)    3.3M           53ms
> >     uncompressed         14M            3ms
> 
> How about the time difference for bootloader to read kernel from
> flash/disk/network to ram?

there are also faster de-compressors than gzip out there. LZ4, for instance.
LZ4, as far as I remember, can be quite fast, like ~10 times faster than gzip.
have you tested it?

	-ss

[toc] | [prev] | [next] | [standalone]


#1608136

FromChao Peng <chao.p.peng@linux.intel.com>
Date2017-03-24 06:40 +0100
Message-ID<toq77-5eW-3@gated-at.bofh.it>
In reply to#1607631
> > > The patch adds a 'CONFIG_KERNEL_RAW' configure choice so the built
> > > binary
> > > can have no uncompressing at all. The experiment shows:
> > > 
> > >     kernel               kernel size    time in decompress_kernel
> > >     compressed (gzip)    3.3M           53ms
> > >     uncompressed         14M            3ms
> > 
> > How about the time difference for bootloader to read kernel from
> > flash/disk/network to ram?

The loading time for bootloader can be longer as size increased, but
that depends on which media it uses. For our usecase, it's not a big
problem. As we run the kernel in virtual machine and lunch thousands of
instances in the same physical machine so only the first instance needs
to read from the file and later we just copy the memory. The thing that
really matters for us is how fast we can boot for majority of the
instances.

> 
> there are also faster de-compressors than gzip out there. LZ4, for
> instance.
> LZ4, as far as I remember, can be quite fast, like ~10 times faster
> than gzip.
> have you tested it?

Exactly, LZ4 is the fastest. It takes 16ms to complete the
decompression. Still sounds a little longer when compared to
uncompressed kernel.

Chao

[toc] | [prev] | [next] | [standalone]


#1609557

FromSebastian Andrzej Siewior <bigeasy@linutronix.de>
Date2017-03-27 10:10 +0200
Message-ID<tpxSW-4Xx-17@gated-at.bofh.it>
In reply to#1608136
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?

> Chao

Sebastian

[toc] | [prev] | [next] | [standalone]


#1609603

FromChao Peng <chao.p.peng@linux.intel.com>
Date2017-03-27 11:30 +0200
Message-ID<tpz8l-5M6-7@gated-at.bofh.it>
In reply to#1609557
On Mon, 2017-03-27 at 09:58 +0200, Sebastian Andrzej Siewior wrote:
> 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?

The usage model for us is to lunch kernel in virtual machine and there
will be thousands of instances lunched and shutdowned/re-lunched
frequently, so every single million-second helps. And 13ms means 20%
improvement to our existing optimization (the other part besides
decompression is optimized to ~40ms).

Chao
> 
> > 
> > Chao
> 
> Sebastian

[toc] | [prev] | [next] | [standalone]


#1609758

FromMichal Marek <mmarek@suse.com>
Date2017-03-27 14:00 +0200
Message-ID<tpBtw-7vp-25@gated-at.bofh.it>
In reply to#1609557
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.

Michal

[toc] | [prev] | [next] | [standalone]


#1609828

FromArnd Bergmann <arnd@arndb.de>
Date2017-03-27 15:30 +0200
Message-ID<tpCSB-hj-9@gated-at.bofh.it>
In reply to#1609758
On Mon, Mar 27, 2017 at 1:47 PM, Michal Marek <mmarek@suse.com> 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

[toc] | [prev] | [next] | [standalone]


#1608203

FromMichal Marek <mmarek@suse.com>
Date2017-03-24 09:30 +0100
Message-ID<tosLD-7cp-3@gated-at.bofh.it>
In reply to#1607460
On 2017-03-23 13:51, Chao Peng wrote:
> Compressed kernel has its own drawback: uncompressing takes time. Even
> though the time is short enough to ignore for most cases but for cases that
> time is critical this is still a big number. In our on-going optimization
> for kernel boot time, the measured overall kernel boot time is ~90ms while
> the uncompressing takes ~50ms with gzip.
> 
> The patch adds a 'CONFIG_KERNEL_RAW' configure choice so the built binary
> can have no uncompressing at all. The experiment shows:
> 
>     kernel               kernel size    time in decompress_kernel
>     compressed (gzip)    3.3M           53ms
>     uncompressed         14M            3ms
> 
> Signed-off-by: Chao Peng <chao.p.peng@linux.intel.com>
> ---
>  arch/x86/boot/compressed/Makefile |  3 +++
>  arch/x86/boot/compressed/misc.c   | 14 ++++++++++++++
>  init/Kconfig                      |  7 +++++++
>  scripts/Makefile.lib              |  8 ++++++++
>  4 files changed, 32 insertions(+)
> 
> diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
> index f9ce75d..fc0e1c0 100644
> --- a/arch/x86/boot/compressed/Makefile
> +++ b/arch/x86/boot/compressed/Makefile
> @@ -73,6 +73,8 @@ $(obj)/vmlinux.relocs: vmlinux FORCE
>  vmlinux.bin.all-y := $(obj)/vmlinux.bin
>  vmlinux.bin.all-$(CONFIG_X86_NEED_RELOCS) += $(obj)/vmlinux.relocs
>  
> +$(obj)/vmlinux.bin.raw: $(vmlinux.bin.all-y) FORCE
> +	$(call if_changed,raw)
>  $(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE
>  	$(call if_changed,gzip)
>  $(obj)/vmlinux.bin.bz2: $(vmlinux.bin.all-y) FORCE
> @@ -86,6 +88,7 @@ $(obj)/vmlinux.bin.lzo: $(vmlinux.bin.all-y) FORCE
>  $(obj)/vmlinux.bin.lz4: $(vmlinux.bin.all-y) FORCE
>  	$(call if_changed,lz4)
>  
> +suffix-$(CONFIG_KERNEL_RAW)	:= raw
>  suffix-$(CONFIG_KERNEL_GZIP)	:= gz
>  suffix-$(CONFIG_KERNEL_BZIP2)	:= bz2
>  suffix-$(CONFIG_KERNEL_LZMA)	:= lzma
> diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
> index 79dac17..fb3cd43 100644
> --- a/arch/x86/boot/compressed/misc.c
> +++ b/arch/x86/boot/compressed/misc.c
> @@ -123,6 +123,20 @@ static char *vidmem;
>  static int vidport;
>  static int lines, cols;
>  
> +#ifdef CONFIG_KERNEL_RAW
> +#include <linux/decompress/mm.h>
> +static int __decompress(unsigned char *buf, long len,
> +			long (*fill)(void*, unsigned long),
> +			long (*flush)(void*, unsigned long),
> +			unsigned char *outbuf, long olen,
> +			long *pos,
> +			void (*error)(char *x))
> +{
> +	memcpy(outbuf, buf, olen);
> +	return 0;
> +}
> +#endif
> +
>  #ifdef CONFIG_KERNEL_GZIP
>  #include "../../../../lib/decompress_inflate.c"
>  #endif
> diff --git a/init/Kconfig b/init/Kconfig
> index 2232080..1db2ea2 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -137,6 +137,13 @@ choice
>  
>  	  If in doubt, select 'gzip'
>  
> +config KERNEL_RAW
> +	bool "RAW"
> +	help
> +	  No compression. It creates much bigger kernel and uses much more
> +	  space (disk/memory) than other choices. It can be useful when
> +	  decompression speed is the most concern while space is not a problem.

This needs to depend on a HAVE_KERNEL_RAW config that is selected by the
architectures that implement this target (x86).

Michal

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web