From owner-svn-src-head@FreeBSD.ORG Tue Jan 8 16:31:26 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7FA9A23C; Tue, 8 Jan 2013 16:31:26 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 23C62B55; Tue, 8 Jan 2013 16:31:25 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.67]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Tsc5C-000D1m-8t; Tue, 08 Jan 2013 08:31:24 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: svn commit: r245147 - head/sys/arm/include From: Oleksandr Tymoshenko In-Reply-To: <20130108155641.GG82219@kib.kiev.ua> Date: Tue, 8 Jan 2013 08:28:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201301080240.r082eKVq080302@svn.freebsd.org> <20130108030022.GC82219@kib.kiev.ua> <50EBA947.1030902@freebsd.org> <20130108155641.GG82219@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1499) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2013-01-08, at 7:56 AM, Konstantin Belousov wrote: > 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 ? >> >> I might misunderstood question so let me rephrase it: >> One physical page P, virtual addresses A and B both mapped to it. Two >> conditions should >> be true: >> >> - if I write word to A+0x200 same value should appear at B+0x200 next >> time it is read >> - If there are no writes to P either through A or B each next read >> 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) ? On ARMv7 - no, it's not possible. On ARMv6 - it seems to be possible from what I gather. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 16:31:26 -0000 On 2013-01-08, at 7:56 AM, Konstantin Belousov = wrote: > 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 >>>>=20 >>>> Log: >>>> Switch default cache type for ARMv6/ARMv7 from write-through to >>>> writeback-writeallocate >>> Could you, please, describe how this is supposed to work. >>>=20 >>> 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) ? On ARMv7 - no, it's not possible. On ARMv6 - it seems to be possible=20= from what I gather.=20 >>=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. >=20 > Hm, it seems, according to the link below, that ARMv6 is affected. >=20 >>=20 >> Some info on subject: >> = http://blogs.arm.com/software-enablement/716-page-colouring-on-armv6-and-a= -bit-on-armv7/ >=20 > 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. >=20 > Thank you for the link.