linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] x86/boot: Support uncompressed kernel
@ 2017-03-23 12:51 Chao Peng
  2017-03-23 15:07 ` Yinghai Lu
  2017-03-24  8:09 ` Michal Marek
  0 siblings, 2 replies; 12+ messages in thread
From: Chao Peng @ 2017-03-23 12:51 UTC (permalink / raw)
  To: H. Peter Anvin, Thomas Gleixner, Ingo Molnar
  Cc: x86, Michal Marek, Kees Cook, Yinghai Lu, Baoquan He, H.J. Lu,
	Paul Bolle, Masahiro Yamada, Chao Peng, Borislav Petkov,
	Andrew Morton, Arnd Bergmann, Petr Mladek, David S. Miller,
	Paul E. McKenney, Andy Lutomirski, Thomas Garnier, Nicolas Pitre,
	Tejun Heo, Daniel Mack, Sebastian Andrzej Siewior,
	Sergey Senozhatsky, Helge Deller, Rik van Riel, linux-kernel,
	linux-kbuild

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

^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [PATCH] x86/boot: Support uncompressed kernel
  2017-03-23 12:51 [PATCH] x86/boot: Support uncompressed kernel Chao Peng
@ 2017-03-23 15:07 ` Yinghai Lu
  2017-03-23 15:31   ` Sergey Senozhatsky
  2017-03-24  8:09 ` Michal Marek
  1 sibling, 1 reply; 12+ messages in thread
From: Yinghai Lu @ 2017-03-23 15:07 UTC (permalink / raw)
  To: Chao Peng
  Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
	the arch/x86 maintainers, Michal Marek, Kees Cook, Baoquan He,
	H.J. Lu, Paul Bolle, Masahiro Yamada, Borislav Petkov,
	Andrew Morton, Arnd Bergmann, Petr Mladek, David S. Miller,
	Paul E. McKenney, Andy Lutomirski, Thomas Garnier, Nicolas Pitre,
	Tejun Heo, Daniel Mack, Sebastian Andrzej Siewior,
	Sergey Senozhatsky, Helge Deller, Rik van Riel,
	Linux Kernel Mailing List, linux-kbuild

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] x86/boot: Support uncompressed kernel
  2017-03-23 15:07 ` Yinghai Lu
@ 2017-03-23 15:31   ` Sergey Senozhatsky
  2017-03-24  5:35     ` Chao Peng
  0 siblings, 1 reply; 12+ messages in thread
From: Sergey Senozhatsky @ 2017-03-23 15:31 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: Chao Peng, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
	the arch/x86 maintainers, Michal Marek, Kees Cook, Baoquan He,
	H.J. Lu, Paul Bolle, Masahiro Yamada, Borislav Petkov,
	Andrew Morton, Arnd Bergmann, Petr Mladek, David S. Miller,
	Paul E. McKenney, Andy Lutomirski, Thomas Garnier, Nicolas Pitre,
	Tejun Heo, Daniel Mack, Sebastian Andrzej Siewior,
	Sergey Senozhatsky, Helge Deller, Rik van Riel,
	Linux Kernel Mailing List, linux-kbuild

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] x86/boot: Support uncompressed kernel
  2017-03-23 15:31   ` Sergey Senozhatsky
@ 2017-03-24  5:35     ` Chao Peng
  2017-03-27  7:58       ` Sebastian Andrzej Siewior
  0 siblings, 1 reply; 12+ messages in thread
From: Chao Peng @ 2017-03-24  5:35 UTC (permalink / raw)
  To: Sergey Senozhatsky, Yinghai Lu
  Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
	the arch/x86 maintainers, Michal Marek, Kees Cook, Baoquan He,
	H.J. Lu, Paul Bolle, Masahiro Yamada, Borislav Petkov,
	Andrew Morton, Arnd Bergmann, Petr Mladek, David S. Miller,
	Paul E. McKenney, Andy Lutomirski, Thomas Garnier, Nicolas Pitre,
	Tejun Heo, Daniel Mack, Sebastian Andrzej Siewior, Helge Deller,
	Rik van Riel, Linux Kernel Mailing List, linux-kbuild


> > > 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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] x86/boot: Support uncompressed kernel
  2017-03-23 12:51 [PATCH] x86/boot: Support uncompressed kernel Chao Peng
  2017-03-23 15:07 ` Yinghai Lu
@ 2017-03-24  8:09 ` Michal Marek
  1 sibling, 0 replies; 12+ messages in thread
From: Michal Marek @ 2017-03-24  8:09 UTC (permalink / raw)
  To: Chao Peng
  Cc: H. Peter Anvin, Thomas Gleixner, Ingo Molnar, x86, Kees Cook,
	Yinghai Lu, Baoquan He, H.J. Lu, Paul Bolle, Masahiro Yamada,
	Borislav Petkov, Andrew Morton, Arnd Bergmann, Petr Mladek,
	David S. Miller, Paul E. McKenney, Andy Lutomirski,
	Thomas Garnier, Nicolas Pitre, Tejun Heo, Daniel Mack,
	Sebastian Andrzej Siewior, Sergey Senozhatsky, Helge Deller,
	Rik van Riel, linux-kernel, linux-kbuild

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] x86/boot: Support uncompressed kernel
  2017-03-24  5:35     ` Chao Peng
@ 2017-03-27  7:58       ` Sebastian Andrzej Siewior
  2017-03-27  9:25         ` Chao Peng
  2017-03-27 11:47         ` Michal Marek
  0 siblings, 2 replies; 12+ messages in thread
From: Sebastian Andrzej Siewior @ 2017-03-27  7:58 UTC (permalink / raw)
  To: Chao Peng
  Cc: Sergey Senozhatsky, Yinghai Lu, H. Peter Anvin, Thomas Gleixner,
	Ingo Molnar, the arch/x86 maintainers, Michal Marek, Kees Cook,
	Baoquan He, H.J. Lu, Paul Bolle, Masahiro Yamada,
	Borislav Petkov, Andrew Morton, Arnd Bergmann, 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

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] x86/boot: Support uncompressed kernel
  2017-03-27  7:58       ` Sebastian Andrzej Siewior
@ 2017-03-27  9:25         ` Chao Peng
  2017-03-27 11:47         ` Michal Marek
  1 sibling, 0 replies; 12+ messages in thread
From: Chao Peng @ 2017-03-27  9:25 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior
  Cc: Sergey Senozhatsky, Yinghai Lu, H. Peter Anvin, Thomas Gleixner,
	Ingo Molnar, the arch/x86 maintainers, Michal Marek, Kees Cook,
	Baoquan He, H.J. Lu, Paul Bolle, Masahiro Yamada,
	Borislav Petkov, Andrew Morton, Arnd Bergmann, 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

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] x86/boot: Support uncompressed kernel
  2017-03-27  7:58       ` Sebastian Andrzej Siewior
  2017-03-27  9:25         ` Chao Peng
@ 2017-03-27 11:47         ` Michal Marek
  2017-03-27 13:25           ` Arnd Bergmann
  1 sibling, 1 reply; 12+ messages in thread
From: Michal Marek @ 2017-03-27 11:47 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior, Chao Peng
  Cc: 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, Arnd Bergmann, 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

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] x86/boot: Support uncompressed kernel
  2017-03-27 11:47         ` Michal Marek
@ 2017-03-27 13:25           ` Arnd Bergmann
  2017-03-28 12:01             ` Chao Peng
  0 siblings, 1 reply; 12+ messages in thread
From: Arnd Bergmann @ 2017-03-27 13:25 UTC (permalink / raw)
  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

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] x86/boot: Support uncompressed kernel
  2017-03-27 13:25           ` Arnd Bergmann
@ 2017-03-28 12:01             ` Chao Peng
  2017-03-28 22:38               ` H. Peter Anvin
  0 siblings, 1 reply; 12+ messages in thread
From: Chao Peng @ 2017-03-28 12:01 UTC (permalink / raw)
  To: Arnd Bergmann, Michal Marek
  Cc: Sebastian Andrzej Siewior, 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

On Mon, 2017-03-27 at 15:25 +0200, Arnd Bergmann wrote:
> 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.

That is something we wanna look into :)

Chao

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] x86/boot: Support uncompressed kernel
  2017-03-28 12:01             ` Chao Peng
@ 2017-03-28 22:38               ` H. Peter Anvin
  2017-03-28 22:55                 ` Andy Lutomirski
  0 siblings, 1 reply; 12+ messages in thread
From: H. Peter Anvin @ 2017-03-28 22:38 UTC (permalink / raw)
  To: Chao Peng, Arnd Bergmann, Michal Marek
  Cc: Sebastian Andrzej Siewior, Sergey Senozhatsky, Yinghai Lu,
	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

On 03/28/17 05:01, Chao Peng wrote:
>>
>> 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.
> 
> That is something we wanna look into :)
> 

It is, but that is a second order thing... especially since the x86
kernel makes heavy use of self-patching at the moment.  What would be
more significant, though, would be to avoid the memcpy() and instead
decode the uncompressed kernel in-place.

	-hpa

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] x86/boot: Support uncompressed kernel
  2017-03-28 22:38               ` H. Peter Anvin
@ 2017-03-28 22:55                 ` Andy Lutomirski
  0 siblings, 0 replies; 12+ messages in thread
From: Andy Lutomirski @ 2017-03-28 22:55 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Chao Peng, Arnd Bergmann, Michal Marek,
	Sebastian Andrzej Siewior, Sergey Senozhatsky, Yinghai Lu,
	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

On Tue, Mar 28, 2017 at 3:38 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 03/28/17 05:01, Chao Peng wrote:
>>>
>>> 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.
>>
>> That is something we wanna look into :)
>>
>
> It is, but that is a second order thing... especially since the x86
> kernel makes heavy use of self-patching at the moment.  What would be
> more significant, though, would be to avoid the memcpy() and instead
> decode the uncompressed kernel in-place.
>

Having looked at this code recently, I'd rather fix it differently:
use the streaming decompression API and integrate it with the ELF
parsing code so we can decompress directly into the actual load
location.  Also, the parse_elf() code needs some serious improved
documentation and robustification.  It's absurdly fragile right now.

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2017-03-28 22:56 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-23 12:51 [PATCH] x86/boot: Support uncompressed kernel Chao Peng
2017-03-23 15:07 ` Yinghai Lu
2017-03-23 15:31   ` Sergey Senozhatsky
2017-03-24  5:35     ` Chao Peng
2017-03-27  7:58       ` Sebastian Andrzej Siewior
2017-03-27  9:25         ` Chao Peng
2017-03-27 11:47         ` Michal Marek
2017-03-27 13:25           ` Arnd Bergmann
2017-03-28 12:01             ` Chao Peng
2017-03-28 22:38               ` H. Peter Anvin
2017-03-28 22:55                 ` Andy Lutomirski
2017-03-24  8:09 ` Michal Marek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).