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

[Jeff Moyer <jmoyer@redhat.com>]

Dave Chinner <david@fromorbit.com> writes:

> On Thu, Feb 25, 2016 at 11:24:57AM -0500, Jeff Moyer wrote:
>> 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.
>
> Essentially I see this situation/request as conceptually the same as
> O_DIRECT for read/write - O_DIRECT bypasses the kernel dirty range
> tracking and, as such, has nasty cache coherency issues when you mix
> it with buffered IO. Nor does it play well with mmap, it has
> different semantics for every filesystem and the kernel code has
> been optimised to the point of fragility.
>
> And, of course, O_DIRECT requires applications to do exactly the
> right things to extract performance gains and maintain data
> integrity. If they get it right, they will be faster than using the
> page cache, but we know that applications often get it very wrong.
> And even when they get it right, data corruption can still occur
> because some thrid party accessed file in a different manner (e.g. a
> backup) and triggered one of the known, fundamentally unfixable
> coherency problems.
>
> However, despite the fact we are stuck with O_DIRECT and it's
> deranged monkeys (which I am one of), we should not be ignoring the
> problems that bypassing the kernel infrastructure has caused us and
> continues to cause us. As such, we really need to think hard about
> whether we should be repeating the development of such a bypass
> feature. If we do, we stand a very good chance of ending up in the
> same place - a bunch of code that does not play well with others,
> and a nightmare to test because it's expected to work and not
> corrupt data...
>
> We should try very hard not to repeat the biggest mistake O_DIRECT
> made: we need to define and document exactly what behaviour we
> guarantee, how it works and exaclty what responsisbilities the
> kernel and userspace have in *great detail* /before/ we add the
> mechanism to the kernel.
>
> Think it through carefully - API changes and semantics are forever.
> We don't want to add something that in a couple of years we are
> wishing we never added....

I agree with everything you wrote, there.

Cheers,
Jeff

--
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>