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

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

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 19:45:26 +0900

 joerg@ wrote:
 
 > >  > >  > (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.
 
 Consider paticular use and background of libsa cread.
 You are claiming the perfect world without consideration
 of cost vs benefit. Unfortunately we have very limited resoures.
 
 On i386 and amd64, gzipped kernels are not used at all.
 Most evbarm gadgets don't use NetBSD's native loader.
 On most other tier II ports, there are a few users and developers
 but we see the slowness just on installation, unlike libarchive
 in pkgsrc etc.
 
 Using existing code (including zlib DYNAMIC_CRC_TABLE version, which
 was used by 4.0 and prior) or removing CRC caluclation is acceptable
 compromise for me, but I don't have extra motivation to pull
 whole new infrastructures in this case. That's why I proposed
 three approach in the PR.
 
 > >  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.
 
 I still don't see actual benefit with measured numbers.
 Furthermore, currently there is no use of external ramdisks.
 No one will bother implement code without visible benefit
 (or just technical interests) so it can't be an alternative
 if there is no working code.  That's all.
 
 Of course, if you claim it's trival and you will work on it,
 I won't object it at all.
 
 ---
 Izumi Tsutsui