| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Yoshimi Ichiyanagi <ichiyanagi(dot)yoshimi(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org, 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-10-02 02:53:18 |
| Message-ID: | 20181002025318.GL11712@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Aug 06, 2018 at 06:00:54PM +0900, Yoshimi Ichiyanagi wrote:
> 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
So you say that this represents a 3% gain based on the presentation?
That may be interesting to dig into it. Could you provide fresher
performance numbers? I am moving this patch to the next CF 2018-10 for
now, waiting for input from the author.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2018-10-02 02:56:19 | Re: inconsistency and inefficiency in setup_conversion() |
| Previous Message | Michael Paquier | 2018-10-02 02:49:05 | Re: WIP: BRIN multi-range indexes |