Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Jun 2014 00:44:27 +0200
From:      Magnus Nilsson <magnus.nilsson@gmail.com>
To:        John-Mark Gurney <jmg@funkthat.com>, freebsd-embedded@freebsd.org,  freebsd-arm <freebsd-arm@freebsd.org>
Cc:        Ian Lepore <ian@freebsd.org>
Subject:   Re: Strange slowdown of zlib.
Message-ID:  <CAHWWKwPS0LtvS1JXvug6DVYJuNH73h3ffZwGT25ffGyd4AEc7A@mail.gmail.com>
In-Reply-To: <20140621140300.GO31367@funkthat.com>
References:  <CAHWWKwM_ETrPGZ1fPc451Hn=iCVEb9Z7qj2X0HEz-znwuR_k=w@mail.gmail.com> <1403193531.20883.269.camel@revolution.hippie.lan> <CAHWWKwNovBV7JouzquNK7kvw66ao9OtJ0uiQEsaftQa%2BDpbT5Q@mail.gmail.com> <20140621140300.GO31367@funkthat.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 21, 2014 at 4:03 PM, John-Mark Gurney <jmg@funkthat.com> wrote:
> Magnus Nilsson wrote this message on Sat, Jun 21, 2014 at 14:13 +0200:
>> 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?
>
> I believe that cp uses mmap instead of the read syscall like cat and
> md5...  So this may be the case...
>
> --
>   John-Mark Gurney                              Voice: +1 415 225 5579
>
>      "All that I will do, has been done, All that I have, has not."

mmap() seems unaffected, well spotted.
Not sure if it would be reasonable to use that fact for a workaround?

I've done more patching and testing.
Mark Tinguely's conservative, unofficial patch
http://lists.freebsd.org/pipermail/freebsd-arm/2010-November/002635.html
does not fix the issue.

Grzegorz Bernacki's proof-of-concept patch
http://lists.freebsd.org/pipermail/freebsd-arm/2010-March/002270.html
/does/ fix the issue! But what's the potential downside?
Debugging issues, as suggested in
http://lists.freebsd.org/pipermail/freebsd-arm/2010-March/002290.html
?
Performance issues? Something worse?

I've looked at later releases (9.3) for backporting, but can't find
anything that that handles PVF_EXEC as a special case like Mark and
Grzegorz.



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