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

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

On Mon, Jan 11, 2016 at 03:00:01PM +0000, Izumi Tsutsui wrote:
>  > I am quite aware of the limited resources, both CPU time
>  > and space.
>  
>  I meant limited human resources. If you have enough spare time
>  to try it, it's fine and no reason to ask other guys.

I haven't hit the problems and I don't have hardware easily at hand that
is slow enough that it matters.

>  > They are not used by default, that doesn't mean it is not used at all.
>  
>  If someone complains slowness on x86, others might look at it.
>  That's all.

It is not noticable on semi-modern hardware. Even the slow version takes
less than 1s, IO is still worse.

>  > Have you spend even 5 seconds to look at the file I pointed to? There is
>  > no new infrastructure. It is pretty much a drop-in replacement of crc32
>  > with a dynamic single byte table computation.
>  
>  The fact is not so simple.

Yes, the fact is that simple.

>  For example, persons who added crc32() into libkern didn't
>  change the function name but did change an argument type,
>  then it caused a conflict against the original zlib one.
>  I cannot simply use zlib/crc32.c and I have to copy code
>  from zlib/crc32.c to slightly modified libkern/crc32.c.

I mentioned the code specifically because it is much easier to use than
the copy & pasting from zlib's dynamic table compution, which is might
be somewhat faster for larger input, but also is larger in terms of code
size. If you had looked, it would be have been quite clear.

Joerg