On Tue, Mar 28, 2017 at 3:38 PM, H. Peter Anvin 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
On Tue, Mar 28, 2017 at 3:38 PM, H. Peter Anvin 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
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
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
On Mon, 2017-03-27 at 15:25 +0200, Arnd Bergmann wrote:
> 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:
> > > >
> > > >
> > > > >
> > > > >
On Mon, 2017-03-27 at 15:25 +0200, Arnd Bergmann wrote:
> 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:
> > > >
> > > >
> > > > >
> > > > > >
> > > > > > >
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 sizetime in decompress_kernel
>> compressed (gzip)3.3M
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 sizetime in decompress_kernel
>> compressed (gzip)3.3M 53ms
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 sizetime in decompress_kernel
> compressed (gzip)3.3M 53ms
> uncompressed 14M3ms
>>
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 sizetime in decompress_kernel
> compressed (gzip)3.3M 53ms
> uncompressed 14M3ms
>>
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 sizetime in
> > > > > decompress_kernel
> > > > > compressed (gzip)3.3M 53ms
>
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 sizetime in
> > > > > decompress_kernel
> > > > > compressed (gzip)3.3M 53ms
>
On 2017-03-24 13:35:40 [+0800], Chao Peng wrote:
>
> > > > kernel kernel sizetime in decompress_kernel
> > > > compressed (gzip)3.3M 53ms
> > > > uncompressed 14M3ms
> > >
> Exactly, LZ4 is the fastest. It takes 16ms to complete the
On 2017-03-24 13:35:40 [+0800], Chao Peng wrote:
>
> > > > kernel kernel sizetime in decompress_kernel
> > > > compressed (gzip)3.3M 53ms
> > > > uncompressed 14M3ms
> > >
> Exactly, LZ4 is the fastest. It takes 16ms to complete the
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
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
> > > The patch adds a 'CONFIG_KERNEL_RAW' configure choice so the built
> > > binary
> > > can have no uncompressing at all. The experiment shows:
> > >
> > > kernel kernel sizetime in decompress_kernel
> > > compressed (gzip)3.3M 53ms
> > >
> > > The patch adds a 'CONFIG_KERNEL_RAW' configure choice so the built
> > > binary
> > > can have no uncompressing at all. The experiment shows:
> > >
> > > kernel kernel sizetime in decompress_kernel
> > > compressed (gzip)3.3M 53ms
> > >
On (03/23/17 08:07), Yinghai Lu wrote:
> On Thu, Mar 23, 2017 at 5:51 AM, 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
On (03/23/17 08:07), Yinghai Lu wrote:
> On Thu, Mar 23, 2017 at 5:51 AM, 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.
On Thu, Mar 23, 2017 at 5:51 AM, 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
On Thu, Mar 23, 2017 at 5:51 AM, 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
22 matches
Mail list logo