On 01/03/18 12:40, Heikki Linnakangas wrote:
> On 16/01/18 15:00, Yoshimi Ichiyanagi wrote:
>> These patches enable to use Persistent Memory Development Kit(PMDK)[1]
>> for reading/writing WAL logs on persistent memory(PMEM).
>> PMEM is next generation storage and it has a number of nice features:
>> fast, byte-addressable and non-volatile.
>
> Interesting. How does this compare with using good old mmap()? I think
> just doing that would allow eliminating much of the complexity around
> managing the shared_buffers. And if the OS is smart about persistent
> memory (I don't know what the state of the art on that is), presumably
> msync() and fsync() on an file that lives in persistent memory is
> lightning fast.
I briefly looked at the docs at pmem.io. pmem_map_file() uses mmap()
under the hood, but it does some extra checks to test if the files is on
a persistent memory device, and makes a note of it.
I think the way forward with this patch would be to map WAL segments
with plain old mmap(), and use msync(). If that's faster than the status
quo, great. If not, it would still be a good stepping stone for actually
using PMDK. If nothing else, it would provide a way to test most of the
code paths, without actually having a persistent memory device, or
libpmem. The examples at http://pmem.io/pmdk/libpmem/ actually sugest
doing exactly that: use libpmem to map a file to memory, and check if it
lives on persistent memory using libpmem's pmem_is_pmem() function. If
it returns yes, use pmem_drain(), if it return false, fall back to using
msync().
- Heikki
