On Tue, Feb 23, 2016 at 3:43 PM, Jeff Moyer <jmoyer@xxxxxxxxxx> wrote: > Dan Williams <dan.j.williams@xxxxxxxxx> writes: > >> On Tue, Feb 23, 2016 at 3:28 PM, Jeff Moyer <jmoyer@xxxxxxxxxx> wrote: >>>> The crux of the problem, in my opinion, is that we're asking for an "I >>>> know what I'm doing" flag, and I expect that's an impossible statement >>>> for a filesystem to trust generically. >>> >>> The file system already trusts that. If an application doesn't use >>> fsync properly, guess what, it will break. This line of reasoning >>> doesn't make any sense to me. >> >> No, I'm worried about the case where an app specifies MAP_PMEM_AWARE >> uses fsync correctly, and fails to flush cpu cache. > > I don't think the kernel needs to put training wheels on applications. > >>>> If you can get MAP_PMEM_AWARE in, great, but I'm more and more of the >>>> opinion that the "I know what I'm doing" interface should be something >>>> separate from today's trusted filesystems. >>> >>> Just so I understand you, MAP_PMEM_AWARE isn't the "I know what I'm >>> doing" interface, right? >> >> It is the "I know what I'm doing" interface, MAP_PMEM_AWARE asserts "I >> know when to flush the cpu relative to an fsync()". > > I see. So I think your argument is that new file systems (such as Nova) > can have whacky new semantics, but existing file systems should provide > the more conservative semantics that they have provided since the dawn > of time (even if we add a new mmap flag to control the behavior). > > I don't agree with that. :) > Fair enough. Recall, I was pushing MAP_DAX not to long ago. It just seems like a Sisyphean effort to push an mmap flag up the XFS hill and maybe that effort is better spent somewhere else. -- 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>