Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

From: Yoshimi Ichiyanagi <ichiyanagi(dot)yoshimi(at)lab(dot)ntt(dot)co(dot)jp>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org
Cc: menjo(dot)takashi(at)lab(dot)ntt(dot)co(dot)jp, ishizaki(dot)teruaki(at)lab(dot)ntt(dot)co(dot)jp
Subject: Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory
Date: 2018-08-06 09:00:54
Message-ID: E9AD42D63FB4ADFAD59E3A1@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I'm sorry for the delay in replying your mail.

<91411837-8c65-bf7d-7ca3-d69bdcb4968a(at)iki(dot)fi>
Thu, 1 Mar 2018 18:40:05 +0800Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote
:
>Interesting. How does this compare with using good old mmap()?

The libpmem's pmem_map_file() supported 2M/1G(the size of huge page)
alignment, since it could reduce the number of page faults.
In addition, libpmem's pmem_memcpy_nodrain() is the function
to copy data using single instruction, multiple data(SIMD) instructions
and NT store instructions(MOVNT).
As a result, using these APIs is faster than using old mmap()/memcpy().

Please see the PGCon2018 presentation[1] for the details.

[1] https://www.pgcon.org/2018/schedule/attachments/507_PGCon2018_Introducing_PMDK_into_PostgreSQL.pdf

<83eafbfd-d9c5-6623-2423-7cab1be3888c(at)iki(dot)fi>
Fri, 20 Jul 2018 23:18:05 +0300Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
wrote :
>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.

I think so too.

I wrote this patch to replace read/write syscalls with libpmem's
API only. I believe that PMDK can make the current PostgreSQL faster.

> 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().

When PMEM_IS_PMEM_FORCE(the environment variable[2]) is set to 1,
pmem_is_pmem() return yes.

Linux 4.15 and more supported MAP_SYNC and MAP_SHARED_VALIDATE of
mmap() flags to check if the mapped file is stored on PMEM.
An application that used both flags in its mmap() call can be sure
that MAP_SYNC is actually supported by both the kernel and
the filesystem that the mapped file is stored in[3].
But pmem_is_pmem() doesn't support this mechanism for now.

[2] http://pmem.io/pmdk/manpages/linux/v1.4/libpmem/libpmem.7.html
[3] https://lwn.net/Articles/758594/

--
Yoshimi Ichiyanagi
NTT Software Innovation Center
e-mail : ichiyanagi(dot)yoshimi(at)lab(dot)ntt(dot)co(dot)jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2018-08-06 10:23:33 Re: TupleTableSlot abstraction
Previous Message Heikki Linnakangas 2018-08-06 07:47:53 Re: [HACKERS] Optional message to user when terminating/cancelling backend