Hi, Dave, Dave Chinner <david@xxxxxxxxxxxxx> writes: > Well, let me clarify what I said a bit here, because I feel like I'm > being unfairly blamed for putting data integrity as the highest > priority for DAX+pmem instead of falling in line and chanting > "Performance! Performance! Performance!" with everyone else. It's totally fair. ;-) > Let me state this clearly: I'm not opposed to making optimisations > that change the way applications and the kernel interact. I like the > idea of MAP_SYNC, but I see this sort of API/behaviour change as a > last resort when all else fails, not a "first and only" optimisation > option. So, calling it "first and only" seems a bit unfair on your part. I don't think anyone asking for a MAP_SYNC option doesn't also want other applications to work well. That aside, this is where your opinion differs from mine: I don't see MAP_SYNC as a last resort option. And let me be clear, this /is/ an opinion. I have no hard facts to back it up, precisely because we don't have any application we can use for a comparison. But, it seems plausible to me that no matter how well you optimize your msync implementation, it will still be more expensive than an application that doesn't call msync at all. This obviously depends on how the application is using the programming model, among other things. I agree that we would need real data to back this up. However, I don't see any reason to preclude such an implementation, or to leave it as a last resort. I think it should be part of our planning process if it's reasonably feasible. > The big issue we have right now is that we haven't made the DAX/pmem > infrastructure work correctly and reliably for general use. Hence > adding new APIs to workaround cases where we haven't yet provided > correct behaviour, let alone optimised for performance is, quite > frankly, a clear case premature optimisation. Again, I see the two things as separate issues. You need both. Implementing MAP_SYNC doesn't mean we don't have to solve the bigger issue of making existing applications work safely. Cheers, Jeff -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>