Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Jun 2014 14:13:01 +0200
From:      Magnus Nilsson <magnus.nilsson@gmail.com>
To:        Ian Lepore <ian@freebsd.org>
Cc:        freebsd-arm <freebsd-arm@freebsd.org>, freebsd-embedded@freebsd.org
Subject:   Re: Strange slowdown of zlib.
Message-ID:  <CAHWWKwNovBV7JouzquNK7kvw66ao9OtJ0uiQEsaftQa%2BDpbT5Q@mail.gmail.com>
In-Reply-To: <1403193531.20883.269.camel@revolution.hippie.lan>
References:  <CAHWWKwM_ETrPGZ1fPc451Hn=iCVEb9Z7qj2X0HEz-znwuR_k=w@mail.gmail.com> <1403193531.20883.269.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 19, 2014 at 5:58 PM, Ian Lepore <ian@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHWWKwNovBV7JouzquNK7kvw66ao9OtJ0uiQEsaftQa%2BDpbT5Q>