Strange slowdown of zlib.

[Magnus Nilsson]

On Thu, Jun 19, 2014 at 5:58 PM, Ian Lepore <ian at freebsd.org> wrote:
> On Thu, 2014-06-19 at 17:44 +0200, Magnus Nilsson wrote:
>> I have the strangest behaviour of zlib on FreeBSD 8.2 (ARM, but I don't
>> think it's necessarily an ARM specific issue).
>> Doing
>> # md5 /lib/libz.so.5
>> or
>> # cp /lib/libz.so.5 /tmp/
>> # export LD_LIBRARY_PATH=/tmp/
>> slows down applications (I've tested bsdtar and gzip) using zlib to a crawl
>> on my system.
>>
>> In the later case, doing
>> # unset LD_LIBRARY_PATH
>> reverts the issue.
>> However, I haven't found any way to recover from the first case, apart from
>> rebooting - then the execution time is back to normal.
>>
>> Here is a log of what I describe above (first moving zlib, then doing the
>> md5):
>> # cp some2MBfile /tmp/
>> # time gzip /tmp/some2MBfile
>> real    0m0.325s
>> user    0m0.284s
>> sys     0m0.037s
>> # rm /tmp/some2MBfile.gz
>> # cp /lib/libz.so.5 /tmp/
>> # export LD_LIBRARY_PATH=/tmp/
>> # cp some2MBfile /tmp/
>> # time gzip /tmp/some2MBfile
>> real    0m11.949s
>> user    0m11.635s
>> sys     0m0.035s
>> # rm /tmp/some2MBfile.gz
>> # unset LD_LIBRARY_PATH
>> # cp some2MBfile /tmp/
>> # time gzip /tmp/some2MBfile
>> real    0m0.325s
>> user    0m0.288s
>> sys     0m0.035s
>> # rm /tmp/some2MBfile.gz
>> # md5 /lib/libz.so.5
>> # cp some2MBfile /tmp/
>> # time gzip /tmp/some2MBfile
>> real    0m11.919s
>> user    0m11.608s
>> sys     0m0.031s
>> # rm /tmp/some2MBfile.gz
>>
>> Do you have any idea what could be going on?
>> Any clues are welcome.
>>
>> Kind regards/Magnus
>
> This is a known problem on armv4/v5 in freebsd 8.  Here is some archived
> info on it including patches that work around the problem (rather
> crudely, but good enough for our needs at $work).
>
> http://lists.freebsd.org/pipermail/freebsd-arm/2012-January/003288.html
>
> -- Ian
>
>

Unfortunately, both your patches from
http://lists.freebsd.org/pipermail/freebsd-arm/2012-January/003288.html
were already in.
Enabling O_DIRECT in ffs_read() in ffs_vnops_icache_hack.bin makes no
difference either.

I have patched r224049, r221844, r212507 and r209223 (r205028 and
r203637 were already in) mentioned by Warner Losh in
http://lists.freebsd.org/pipermail/freebsd-arm/2012-January/003292.html
in case they'd make any difference, but no.

If I run Maks Verver's simple testcase from
http://lists.freebsd.org/pipermail/freebsd-arm/2010-March/002243.html
, it consistently runs ~15s on my 1GHz CPU.
After 'cat testcase > /dev/null', it takes ~14min of course.

While e.g. cat or md5 of an executable affects its speed, e.g. cp does not.
Could there be some read access that's unaffected by your patches?

(As I said privately, thank you very much for setting me on the right track!)

KR/Magnus