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

Groups > linux.kernel > #1610626 > unrolled thread

Re: [PATCH] x86/boot: Support uncompressed kernel

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] x86/boot: Support uncompressed kernel Chao Peng <chao.p.peng@linux.intel.com> - 2017-03-28 14:10 +0200
    Re: [PATCH] x86/boot: Support uncompressed kernel "H. Peter Anvin" <hpa@zytor.com> - 2017-03-29 01:00 +0200
      Re: [PATCH] x86/boot: Support uncompressed kernel Andy Lutomirski <luto@amacapital.net> - 2017-03-29 01:00 +0200

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

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

[toc] | [next] | [standalone]

#1611423

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

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

#1611424

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web