Date: Tue, 8 Jan 2013 17:56:41 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Oleksandr Tymoshenko <gonzo@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r245147 - head/sys/arm/include Message-ID: <20130108155641.GG82219@kib.kiev.ua> In-Reply-To: <50EBA947.1030902@freebsd.org> References: <201301080240.r082eKVq080302@svn.freebsd.org> <20130108030022.GC82219@kib.kiev.ua> <50EBA947.1030902@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--26XRljEL7Ier68ao Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 07, 2013 at 09:06:15PM -0800, Oleksandr Tymoshenko wrote: > On 1/7/2013 7:00 PM, Konstantin Belousov wrote: > > On Tue, Jan 08, 2013 at 02:40:20AM +0000, Oleksandr Tymoshenko wrote: > >> Author: gonzo > >> Date: Tue Jan 8 02:40:20 2013 > >> New Revision: 245147 > >> URL: http://svnweb.freebsd.org/changeset/base/245147 > >> > >> Log: > >> Switch default cache type for ARMv6/ARMv7 from write-through to > >> writeback-writeallocate > > Could you, please, describe how this is supposed to work. > > > > Assume that a process mapped the same file page at two different > > addresses, both read-write, and writes to both mappings. Usermode code > > does not consider the need to flush caches or synchronize writes into > > non-overlapping regions, usually. Would it break, i.e. could the values > > appear in the page which were never written to it ? >=20 > I might misunderstood question so let me rephrase it: > One physical page P, virtual addresses A and B both mapped to it. Two=20 > conditions should > be true: >=20 > - if I write word to A+0x200 same value should appear at B+0x200 next= =20 > time it is read > - If there are no writes to P either through A or B each next read=20 > should yield same result. I am more concerned with the following: assume that current content in the page is 0x200:u, 0x201:v, and a byte x was written at A+0x200, byte y at B+0x201. Is it possible that future read of the bytes at A+0x200, A+0x201 (on the same core) returns (x, v) ? >=20 > These conditions are met for ARMv7 devices for both WT and WBWA caches.= =20 > They're PIPT > so no aliasing in this case. Up until now I believed that "no aliasing"= =20 > is true for all ARM CPUs > we target but quick check proved me wrong: ARM1176 on which Raspberry Pi > is based is prone to cache aliasing problem. Which might explain memory= =20 > corruption > easily reproducible under load. Again the problem is not related to=20 > cache type itself but > to the lack of handling of this situation in pmap module. I am trying to find a way through the ARM ARM and some additional texts. Could it be that cache aliasing is only limited to the I-cache on ARM, at least for recent cores ? My concern is hopefully not valid than. Hm, it seems, according to the link below, that ARMv6 is affected. >=20 > Some info on subject: > http://blogs.arm.com/software-enablement/716-page-colouring-on-armv6-and-= a-bit-on-armv7/ This seems to support the idea that mmap does not work on ARM, at least for ARMv6. It seems that sf buffers do not obey the arch requirements for aliasing as well. Thank you for the link. >=20 > Thank you for raising this topic. I hope people more ARM-savvy then me= =20 > can confirm or refute > my point of view. >=20 > > > > Another similar question, sf buffers on ARM flush the cache on sf_buf_f= ree() > > (sometimes). If the page, for which the sf buffer is created, mapped in= to > > the userspace read-write, could it be that a value appears that was nev= er > > written ? Note that sf buffers are used e.g. by uiomove_fromphys(). > I believe the stuff above is applicable to this question too. --26XRljEL7Ier68ao Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ7EG4AAoJEJDCuSvBvK1BxroP/REtvf7+RNuafkf6qYTfP/yV zngWz3OasRTmBmuPY9tgJMdt2LpQ9amCBIPELe3Tr2NHFxXmwCtDL6LG/gAHC9Wl eAQDqlOYYexhZ221NWHQYNcv7fRh80YRzXxQeCLefRgYPpNoZ7uhJaXm1ZAUxSC+ 2Ubs6TWsPqnXjr53TqaLJFZobAZXy5D18sK2EddyRMtE3YFfkFwCz7SD/qUIeBZ8 qT/Sv4DyaDouF/MgdZLAEtTs9o4XnzpueBsGnEfAG6csSeSTk8seCq1cAQUdVLac VbxWGANaLq4qnHvzdS+z7Tdtl/CxDpbeuthw0W1H4wu29ATsyIWC2JCxfw1/g0cO H7M9XN1K+ziFMkdI1CUfVoEGT+CakWDYVvvlI2vc09Ydh87qnxFNGf9N+fOHyRNX F/MZerIHWUpqLyYQNppgmvhMhXTYxd4PPmM8Ci7iLfAA66owCIBXIJ7eabk2JFVb dEFpbXrZh6AtTvUdrDysk+kE+EFpqtDW0dHIfIk09RoIf2jCgoW5AZ/SrL0QQR3I N/FUqcPTLidKervOAgZzsx2zefFYUNzt7YZF+SA9Z8olS9E4QBsqeaF4ID85AuyP RAKQtPhnIy2WAUWdrl30ICKacsY++IlG3VmTcfE9Vkkpen62iD2KLCVYnmfLAERw TTuaTtF2OceuycM+cCCz =yDzv -----END PGP SIGNATURE----- --26XRljEL7Ier68ao--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130108155641.GG82219>