Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1264774
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness |
| Date | 2015-11-07 10:30 +0100 |
| Message-ID | <qs7YS-qx-11@gated-at.bofh.it> (permalink) |
| References | (8 earlier) <qs01j-3vl-3@gated-at.bofh.it> <qs5DI-7fZ-5@gated-at.bofh.it> <qs6T7-8cb-1@gated-at.bofh.it> <qs7m9-8o7-5@gated-at.bofh.it> <qs7Fv-jH-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Dan Williams <dan.j.williams@intel.com> - 2015-11-06 01:00 +0100
Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Thomas Gleixner <tglx@linutronix.de> - 2015-11-06 09:10 +0100
Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Dan Williams <dan.j.williams@intel.com> - 2015-11-06 17:10 +0100
Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Thomas Gleixner <tglx@linutronix.de> - 2015-11-06 18:40 +0100
Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Dan Williams <dan.j.williams@intel.com> - 2015-11-07 00:20 +0100
Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness "H. Peter Anvin" <hpa@zytor.com> - 2015-11-07 02:00 +0100
Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Thomas Gleixner <tglx@linutronix.de> - 2015-11-07 08:00 +0100
Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Dan Williams <dan.j.williams@intel.com> - 2015-11-07 09:20 +0100
Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Thomas Gleixner <tglx@linutronix.de> - 2015-11-07 09:50 +0100
Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Dan Williams <dan.j.williams@intel.com> - 2015-11-07 10:10 +0100
Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness Thomas Gleixner <tglx@linutronix.de> - 2015-11-07 10:30 +0100
Re: [PATCH 0/2] "big hammer" for DAX msync/fsync correctness "H. Peter Anvin" <hpa@zytor.com> - 2015-11-06 21:30 +0100
csiph-web