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

[Boaz Harrosh <boaz@plexistor.com>]

On 02/23/2016 07:25 PM, Ross Zwisler wrote:
<>
> 
> It seems like we are trying to solve a couple of different problems:
> 
> 1) Make page faults faster by skipping any radix tree insertions, tag updates,
> etc.
> 
> 2) Make fsync/msync faster by not flushing data that the application says it
> is already making durable from userspace.
> 

I fail to see how this is separate issues the reason you are keeping track
of pages in [1] is exactly because you want to know which are they in [2].
Only [2] matters and [1] is what you thought is a necessary cost.
If you remember I wanted to solve [1] differently by iterating over the
extent lists of the mmap range and cl_flushing all the "written" pages in the
range not only the written ones. In our testes we found that for  most real world
applications and benchmarks this works better then your approach. because
page-faults are fast.
There is however work loads that are much worse. In anyway your way was easier
because it had a generic solution instead of an FS specific implementation.

> I agree that your approach seems to improve both of these problems, but I
> would argue that it is an incomplete solution for problem #2 because a
> fsync/msync from the PMEM aware application would still flush any radix tree
> entries from *other* threads that were writing to the same file.
> 

No!! you meant applications. Because threads are from the same application if
a programmer is dumb enough to upgrade one mmap call site to new and keep
all other sites legacy without the flag and pmem_mecpy, then he can suffer, I do
not care for dumb programmers.

For the two applications one new one legacy writing to the same file each written
by a different team of programmers. For one they do not exist. But for two
this is an administrator issue. Yes if he allows such a setup he knows that the
performance will not be has if both apps upgraded but it will still be better then
two legacy apps. because at least all the pages from the new app will not slow-sync.

> It seems like a more direct solution for #2 above would be to have a
> metadata-only equivalent of fsync/fdatasync, say "fmetasync", which says "I'll
> make the writes I do to my mmaps durable from userspace, but I need you to
> sync all filesystem metadata for me, please".
> 
> This would allow a complete separation of data synchronization in userspace
> from metadata synchronization in kernel space by the filesystem code.
> 
> By itself a fmetasync() type solution of course would do nothing for issue #1
> - if that was a compelling issue you'd need something like the mmap tag you're
> proposing to skip work on page faults.
> 

Again a novelty solution to a theoretical only problem. With only very marginal
performance gains. And no users that I can see. And lots of work including FS
specific work.

> All that being said, though, I agree with others in the thread that we should
> still be focused on correctness, as we have a lot of correctness issues
> remaining.  When we eventually get to the place where we are trying to do
> performance optimizations, those optimizations should be measurement driven.
> 

What I'm hopping to do is establish a good practice for pmem aware apps
that everyone can agree on and will give us ground to optimize for.
That pmem apps can start to be written and experimented with.

The patch I sent is so simple and none intrusive that it can be easily
be carried in the noise and I cannot see how it breaks anything. And yes
I am measurement driven and is why I even bother.

And hence the RFC let us establish a programming model first.

> - Ross
> 

Thanks
Boaz

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