Re: [RFC 0/2] New MAP_PMEM_AWARE mmap flag

[Dan Williams <dan.j.williams@intel.com>]

On Tue, Feb 23, 2016 at 3:43 PM, Jeff Moyer <jmoyer@redhat.com> wrote:
> Dan Williams <dan.j.williams@intel.com> writes:
>
>> On Tue, Feb 23, 2016 at 3:28 PM, Jeff Moyer <jmoyer@redhat.com> 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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>