On Tue, May 03, 2016 at 06:30:04PM +0000, Rudoff, Andy wrote: > > > >And when the filesystem says no because the fs devs don't want to > >have to deal with broken apps because app devs learn that "this is a > >go fast knob" and data integrity be damned? It's "fsync is slow so I > >won't use it" all over again... > ... > > > >And, please keep in mind: many application developers will not > >design for pmem because they also have to support traditional > >storage backed by page cache. If they use msync(), the app will work > >on any storage stack, but just be much, much faster on pmem+DAX. So, > >really, we have to make the msync()-only model work efficiently, so > >we may as well design for that in the first place.... > > Both of these snippets seem to be arguing that we should make msync/fsync > more efficient. But I don't think anyone is arguing the opposite. Is > someone saying we shouldn't make the msync()-only model work efficiently? Not directly. The argument presented is "we need a flag to avoid msync, because msync is inefficient", which is followed by "look, here's numbers that show msync() being slow, so just give us the flag already". Experience tells me that the moment a workaround is in place, nobody will go back and try to fix the problem that the workaround is mitigating. Now we know that it's the page granularity cache flushing overhead that causes the performance differential rather than it being caused by using msync(), we should be looking at ways to reduce the cache flushing overhead, not completely bypassing it. > Said another way: the common case for DAX will be applications simply > following the POSIX model. open, mmap, msync... That will work fine > and of course we should optimize that path as much as possible. Less > common are latency-sensitive applications built to leverage to byte- > addressable nature of pmem. File systems supporting this model will > indicate it using a new ioctl that says doing CPU cache flushes is > sufficient to flush stores to persistence. You keep saying this whilst ignoring the repeated comments about how this can not be guaranteed by all filesystems, and hence apps will not be able to depend on having such behaviour present. The only guarantee for persistence that an app will be able to rely on is msync(). > But I don't see how that > direction is getting turned into an argument against msync() efficiency. Promoting a model that works around inefficiency rather than solving it is no different to saying you don't care about fixing the inefficiency.... I've said my piece, I'm not going to waste any more time going around this circle again. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
