Date: Sat, 5 May 2018 18:14:38 +0200 From: Mateusz Guzik <mjguzik@gmail.com> To: Alexey Dokuchaev <danfe@freebsd.org> Cc: Bruce Evans <brde@optusnet.com.au>, Conrad Meyer <cem@freebsd.org>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, Brooks Davis <brooks@freebsd.org>, src-committers <src-committers@freebsd.org> Subject: Re: svn commit: r333240 - in head/sys: powerpc/powerpc sys Message-ID: <CAGudoHE%2BsTCnd8sgsos7A%2BE33=LpEevZ=0UFhMUgBVp5JKHJ-w@mail.gmail.com> In-Reply-To: <20180505120055.GA81833@FreeBSD.org> References: <201805040400.w4440moH025057@repo.freebsd.org> <20180504155301.GA56280@spindle.one-eyed-alien.net> <CAG6CVpUr_2b-yT1-uExcY1Tvpg=-P3y_owNHQ0UPg604to8Y0Q@mail.gmail.com> <20180505090954.X1307@besplex.bde.org> <20180505120055.GA81833@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 5, 2018 at 2:00 PM, Alexey Dokuchaev <danfe@freebsd.org> wrote: > On Sat, May 05, 2018 at 10:38:29AM +1000, Bruce Evans wrote: > > ... > > Summary: this change wouldn't have passed my review. I have used similar > > changes for 15-20 years but never made them production quality since > there > > are too many variations to consider and testing showed insignificant > > improvements except for micro-benchmarks. > > Perhaps Foundation could sponsor your work to make them production quality > Bruce. :-) > > Seriously though, I'm a bit worried to see these commits happening at the > same time correctness of the implementation is still under discussion and > disputes. Shall I expect that after my next -CURRENT update things would > suddenly stop working? [1] > > ./danfe > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=638477 > > Nothing of the sort was done here. They had a memcpy function which internally behaved like memmove. They changed to behave like mere memcpy (i.e. assume non-overlapping buffers). This caused buggy code to run into trouble. bcopy has memmove semantics and this change keeps that. The only difference is that instead of always generating a call, the compiler is allowed to perform the copy in place in certain cases. This is precisely what happens almost everywhere and it was not happening in the kernel because of a giant hammer -fno-builtin flag (added to reduce changes the compiler will do stuff the kernel does not want to deal with). -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGudoHE%2BsTCnd8sgsos7A%2BE33=LpEevZ=0UFhMUgBVp5JKHJ-w>