Date: Tue, 2 Jun 2009 13:39:28 -0500 (CDT) From: Mark Tinguely <tinguely@casselton.net> To: sam@freebsd.org, tinguely@casselton.net Cc: freebsd-arm@freebsd.org Subject: Re: cache corruption patch Message-ID: <200906021839.n52IdSrY002806@casselton.net> In-Reply-To: <4A25566C.7020806@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Have you measured the overhead of this additional state tracking > (time+space)? It appears to affect only dma buffers. no, I haven't tracked the overhead of tracking and turning off the cache for the multiply mapped page versus flushing the entire cache. For space, the patch costs us 4 bytes/page. I removed 16 bytes/page when I re-implemented the cache fixing routines (from pmap_vac_me_harder() from NetBSD and in -7.x to pmap_fix_cache() which is new for -8.x). The main reason to re-implement the cache fixing routines was to fix the "big O" factor on the routines. Right now we have the potential of stale caches any time a kernel mapped page is shared with a user or another kernel mapping. Things like mmap comes to mind. > Not sure what "added cache invalidation commands" you're referring to, > can you explain? Perhaps you could just provide a separate patch that > shows which bus_dma ops you think can go away. Yes, without the patch, some people placed cache flushes in the DMA sync routines. That did solve the obvious problem. Those flushes are not in the ARM code and the patch does not remove them. A few months back, when new USB stack brought the cache problems to the foreground, others mention strange intermittent memory corruption that pointed to stale caches. We could start sticking in cache flushes for each new one that pops up, but it seemed like a game of russian roulette. --Mark.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200906021839.n52IdSrY002806>