Re: bin/50638: Extreme slowness on loading gzipped kernels on oldCPUs

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

The following reply was made to PR bin/50638; it has been noted by GNATS.

From: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: bin/50638: Extreme slowness on loading gzipped kernels on oldCPUs
Date: Wed, 13 Jan 2016 16:36:13 +0100

 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