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: Mon, 11 Jan 2016 11:10:16 +0100

 On Mon, Jan 11, 2016 at 02:00:01AM +0000, Izumi Tsutsui wrote:
 > The following reply was made to PR bin/50638; it has been noted by GNATS.
 > 
 > From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
 > To: joerg%britannica.bec.de@localhost
 > Cc: gnats-bugs%NetBSD.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
 > Subject: Re: bin/50638: Extreme slowness on loading gzipped kernels on oldCPUs
 > Date: Mon, 11 Jan 2016 10:56:51 +0900
 > 
 >  > >  > (3) completely disable gunzip crc32() calculation in cread() function
 >  > >  
 >  > >  My vote is on (3).
 >  > >  
 >  > >  Thanks for dealing with this!
 >  > 
 >  > Can you try the faster crc32 from libarchive? It doesn't add much code
 >  > and IMO having the verification is quite useful.
 >  
 >  It looks like Armchair Detective's comments.
 
 Can you please try to avoid calling people names without even looking at
 the suggestions? We have been running into a situation very similar in
 libarchive, where the original dumb crc32 implementation created
 significant performance impact. The new fallback version is only
 slightly larger than the dumb version, both in terms of number of source
 lines and code size. It was fast enough for libarchive's purpose and it
 should be fast enough for input the size of the ramdisk kernels on
 slower systems.
 
 >  What's your comment about the following sentence in the original PR?
 >  
 >  >> * Pros. and cons:
 >   :
 >  >> (3) it looks CRC is not used in most case;
 >  >>     the CRC can be confirmed when the whole file contents are read,
 >  >>     but our libsa loadfile() finction loads only text, data, bss,
 >  >>     and symbol table, which could also be padded by ldscript.
 >  
 >  How can your suggestion be useful and appropriate for implementation cost?
 
 Even if it is not used in some cases, we can load full compressed files
 e.g. for external ramdisks. Because trying to castrate a functionality,
 it much better to look if there is a trivial fix. The suggestion does
 exactly that.
 
 Joerg