Date: Wed, 23 May 2012 15:08:10 +0200 From: Svatopluk Kraus <onwahe@gmail.com> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: Richard Hodges <richard@hodges.org>, freebsd-arm@freebsd.org, hackers@freebsd.org Subject: Re: ARM + CACHE_LINE_SIZE + DMA Message-ID: <CAFHCsPXoVPpx2sfGB3C5pSSLUBUdz9E_CbcoscHAf%2B0uwm=itQ@mail.gmail.com> In-Reply-To: <1337617221.2516.38.camel@revolution.hippie.lan> References: <CAFHCsPUdZXGKFvmVGgaEUsfhwd28mNVGaY84ExcJp=ogQxzPJQ@mail.gmail.com> <1337285248.1503.308.camel@revolution.hippie.lan> <CAFHCsPVxkhNfiTQp7gvjfonfTjoG-28RgNrG=%2BdxbGhzxqY%2BDg@mail.gmail.com> <1337617221.2516.38.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 21, 2012 at 6:20 PM, Ian Lepore <freebsd@damnhippie.dyndns.org> wrote: >> ... >> Some more notes. >> >> SMP makes things worse and ARM11mpcore is about SMP too. For example, >> another thread could be open about that how to flush caches (exclusive >> L1 cache) in SMP case. >> >> I'm not sure how to correctly change memory attributes on page which >> is in use. Making new temporary mapping with different attributes is >> wrong and does not help at all. It's question how to do TLB and cache >> flushes on two and more processors and be sure that everything is OK. >> It could be slow and maybe, changing memory attributes on the fly is >> not a good idea at all. >> > > My suggestion of making a temporary writable mapping was the answer to > how to correctly change memory attributes on a page which is in use, at > least in the existing code, which is for a single processor. > > You don't need, and won't even use, the temporary mapping. =A0You would > make it just because doing so invokes logic in arm/arm/pmap.c which will > find all existing virtual mappings of the given physical pages, and > disable caching in each of those existing mappings. =A0In effect, it make= s > all existing mappings of the physical pages DMA_COHERENT. =A0When you > later free the temporary mapping, all other existing mappings are > changed back to being cacheable (as long as no more than one of the > mappings that remain is writable). > > I don't know that making a temporary mapping just for its side effect of > changing other existing mappings is a good idea, it's just a quick and > easy thing to do if you want to try changing all existing mappings to > non-cacheable. =A0It could be that a better way would be to have the > busdma_machdep code call directly to lower-level routines in pmap.c to > change existing mappings without making a new temporary mapping in the > kernel pmap. =A0The actual changes to the existing mappings are made by > pmap_fix_cache() but that routine isn't directly callable right now. > Thanks for explanation. In fact, I known only a little about current ARM pmap implementation in FreeBSD tree. I took i386 pmap implementation and modified it according to arm11mpcore. > Also, as far as I know all of this automatic disabling of cache for > multiple writable mappings applies only to VIVT cache architectures. > I'm not sure how the pmap code is going to change to support VIPT and > PIPT caches, but it may no longer be true that making a second writable > mapping of a page will lead to changing all existing mappings to > non-cacheable. > > -- Ian Svata
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPXoVPpx2sfGB3C5pSSLUBUdz9E_CbcoscHAf%2B0uwm=itQ>