NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/50638: Extreme slowness on loading gzipped kernels on oldCPUs
On Tue, Jan 12, 2016 at 12:35:01PM +0000, Martin Husemann wrote:
> The following reply was made to PR bin/50638; it has been noted by GNATS.
>
> From: Martin Husemann <martin%duskware.de@localhost>
> To: gnats-bugs%netbsd.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
> Cc:
> Subject: Re: bin/50638: Extreme slowness on loading gzipped kernels on oldCPUs
> Date: Tue, 12 Jan 2016 13:31:26 +0100
>
> And the ideal variant would do it in:
>
> > non compressed kernel:
> >
> > 1452589100:570546000: > boot netbsd
> > 1452589150:429907000: Copyright(c)...
> > = 49.8594s
>
> + total time for one full decompression:
>
> # ls -l netbsd
> -rw-r--r-- 1 root wheel 1827667 Jan 12 09:04 netbsd
> # file netbsd
> netbsd: gzip compressed data, last modified: Tue Jan 12 08:05:45 2016, max compression, from Unix
> # /usr/bin/time gzcat netbsd >/dev/null
> 29.96 real 23.04 user 1.78 sys
>
> ... so like 80s.
This strongly suggests that a lot of seeking happens and the input is
processed multiple times. Is there a very good reason for not just
sucking in the whole kernel in one go or at least use a resize+read loop
once we know that it is an ELF binary we are interested in?
Joerg
Home |
Main Index |
Thread Index |
Old Index