On Thu, May 31, 2018 at 8:31 AM, Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > > > On Thu, 31 May 2018, Dan Williams wrote: > >> On Thu, May 31, 2018 at 1:19 AM, Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: >> > >> > >> > On Wed, 30 May 2018, Dan Williams wrote: >> > >> >> > Great find! Thanks for the due diligence. Feel free to add: >> >> > >> >> > Acked-by: Dan Williams <dan.j.williams@xxxxxxxxx> >> >> > >> >> > ...on the reworks to unify ARM and x86. >> >> >> >> One more note. The side effect of not using dax_flush() is that you >> >> may end up flushing caches on systems where the platform has asserted >> >> it will take responsibility for flushing caches at power loss. If / >> >> when those systems become more prevalent we may want to think of a way >> >> to combine the non-temporal optimization and the cache-flush-bypass >> >> optimizations. However that is something that can wait for a later >> >> change beyond 4.18. >> > >> > We could define memcpy_flushpmem, that falls back to memcpy or >> > memcpy_flushcache, depending on whether the platform flushes the caches at >> > power loss or not. >> >> The problem is that some platforms only power fail protect a subset of >> the physical address range, > > How can this be? A psysical address may be cached on any CPU, so either > there is enough power to flush all the CPUs' caches or there isn't. > > How does the CPU design that protects only a part of physical addresses > look like? It's not necessarily a CPU problem, it may be a problem of having enough stored energy to potentially software loops to flush caches. There's also the consideration that a general purpose platform may mix persistent memory technologies from different vendors where some might be flash-backed DRAM and some might be persistent media directly. For now I don't think we need to worry about it, but I don't want to make the assumption that this property is platform global given the history of how persistent memory has been deployed to date. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
