Date: Mon, 26 Oct 2009 13:53:47 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: Marius Strobl <marius@alchemy.franken.de> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r198341 - in head/sys: amd64/amd64 arm/arm arm/mv i386/i386 i386/xen ia64/ia64 kern mips/mips powerpc/aim powerpc/booke powerpc/include powerpc/powerpc sparc64/sparc64 sun4v/sun4v vm Message-ID: <63FB238C-D66F-486B-AB5B-DA7C2423A78B@mac.com> In-Reply-To: <20091026201116.GS27159@alchemy.franken.de> References: <200910211838.n9LIc2wp007206@svn.freebsd.org> <20091025202541.GC94979@alchemy.franken.de> <36313C38-9B60-4BF3-885C-5BAAA915DCFE@mac.com> <20091026201116.GS27159@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 26, 2009, at 1:11 PM, Marius Strobl wrote: > The cheetah-class CPUs, i.e. USIII and later, take care of > I$ coherency themselves, unlike the spitfire ones (see also > cheetah_icache_page_inval() vs. spitfire_icache_page_inval()). This explains why I didn't see any I-cache coherency issues :-) > I currently can't think of any existing code which would > ensure I$ consistency after the writes have been performed, > not even as a side-effect. The proper solution probalby is to > make pmap_sync_icache() a wrapper around icache_page_inval(). I concur. Do we have any spitfire-based sparc64 boxes in the cluster or do you have one? -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?63FB238C-D66F-486B-AB5B-DA7C2423A78B>