Messages in this thread | | | Date | Sat, 7 Nov 2015 10:24:06 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness |
| |
On Sat, 7 Nov 2015, Dan Williams wrote: > Thanks for that explanation. Peter had alluded to it at KS, but I > indeed did not know that it was as horrible as milliseconds of > latency, hmm...
Yes, I was pretty surprised as well. But even if it's just in the hundreds of microseconds it can be too much for latency sensitive applications.
> One other mitigation that follows on with Dave's plan of per-inode DAX > control, is to also track when an inode has a writable DAX mmap > established. With that we could have a REQ_DAX flag to augment > REQ_FLUSH to potentially reduce committing violence on the cache. In > an earlier thread I also recall an idea to have an mmap flag that an > app can use to say "yes, I'm doing a writable DAX mapping, but I'm > taking care of the cache myself". We could track innocent cpus, but > I'm thinking that would be a core change to write-protect pages when a > thread migrates? In general I feel there's a limit for how much > hardware workaround is reasonable to do in the core kernel vs waiting > for the platform to offer better options...
One thing vs. the mmaps: We exactly know which CPUs are involved in that mapping. We know that from the TLB management. So we probably can make use of that knowledge.
> Sorry if I'm being a bit punchy, but I'm still feeling like I need to > defend the notion that DAX may just need to be turned off in some > situations.
That's fine, if there is no reasonable way around it. It just needs to be documented so people won't be surprised.
Thanks,
tglx
| |