Date: Wed, 05 Mar 2014 06:22:47 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r262411 - head/sys/arm/arm Message-ID: <1394025767.1149.327.camel@revolution.hippie.lan> In-Reply-To: <20140305115402.GC24664@kib.kiev.ua> References: <201402232252.s1NMqmI5075701@svn.freebsd.org> <20140305115402.GC24664@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2014-03-05 at 13:54 +0200, Konstantin Belousov wrote: > On Sun, Feb 23, 2014 at 10:52:48PM +0000, Ian Lepore wrote: > > Author: ian > > Date: Sun Feb 23 22:52:48 2014 > > New Revision: 262411 > > URL: http://svnweb.freebsd.org/changeset/base/262411 > > > > Log: > > If the L2 cache type is PIPT, pass a physical address for a flush. > > > > While this is technically more correct, I don't think it much matters, > > because the only thing in the tree that calls cpu_flush_dcache() is md(4) > > and I'm > 99% sure it's bogus that it does so; md has no ability to do > > anything that can perturb data cache coherency. > > Yes, md(4) does not break data cache coherency, but I think that > Marcel added the flush to ensure instruction cache coherency. The > intent was to ensure that harward-architecture machines would > see up-to-date memory content when fetching instructions after > read on md(4). Oh. If that's necessary on ia64, it seems like ia64/elf_machdep.c would be the place to do the flush. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1394025767.1149.327.camel>