[
https://issues.apache.org/jira/browse/HBASE-21874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16768949#comment-16768949
]
Anoop Sam John edited comment on HBASE-21874 at 2/15/19 6:03 AM:
-----------------------------------------------------------------
bq.Why add the configurable buffer size? That seems to be what most of the
patch is about which is distracting.
We can remove that part if it is distracting but it may be needed if you need
to create bigger sized cache. It seems like a java restriction from mmapping
buffers.
Now the PmemIOEngine uses the FileMmapEngine ( we can make isPersistent -
false), but it is simple way to show how we can show a replacement of DRAM
IOEngine. But pls note in FileMmapEngine
{code:java}
return deserializer.deserialize(new SingleByteBuff(ByteBuffer.wrap(dst)), true,
MemoryType.EXCLUSIVE);{code}
where as here in PmemIOEngine
{code:java}
return deserializer.deserialize(dstBuffer, true, MemoryType.SHARED);{code}
So it becomes a direct replacement of the DRAM based IOEngine. ( you don't copy
the buffers onheap)
bq. I do not see any dependency on pmem libs, such as this one: [pmem
java|https://github.com/pmem/llpl],
These libraries are for guaranteeing the persistence nature in the underlying
devices after power cycles. We are not trying to have a persistent based cache
where we need to regain the data back after a restart. The llpl library that
you pointed is a Java wrapper on
[http://pmem.io/.|http://pmem.io/]
This native library assures durability by memory mapping the file on the Pmem
device.
See the notes here (Copied from https://pmem.io/pmdk/)
{code:java}
The Persistent Memory Development Kit, PMDK, is a growing collection of
libraries which have been developed for various use cases, tuned, validated to
production quality, and thoroughly documented. These libraries build on the
Direct Access (DAX) feature available in both Linux and Windows, which allows
applications direct load/store access to persistent memory by memory-mapping
files on a persistent memory aware file system.{code}
So Java's memory mapping itself allows us to get that capability.
If we want the persistence nature of the cache then yes we need to go with LLPL
library but that can be taken as next step.
was (Author: ram_krish):
bq.Why add the configurable buffer size? That seems to be what most of the
patch is about which is distracting.
We can remove that part if it is distracting but it may be needed if you need
to create bigger sized cache. It seems like a java restriction from mmapping
buffers.
Now the PmemIOEngine uses the FileMmapEngine ( we can make isPersistent -
false), but it is simple way to show how we can show a replacement of DRAM
IOEngine. But pls note in FileMmapEngine
{code:java}
return deserializer.deserialize(new SingleByteBuff(ByteBuffer.wrap(dst)), true,
MemoryType.EXCLUSIVE);{code}
where as here in PmemIOEngine
{code:java}
return deserializer.deserialize(dstBuffer, true, MemoryType.SHARED);{code}
So it becomes a direct replacement of the DRAM based IOEngine. ( you don't copy
the buffers onheap)
bq. I do not see any dependency on pmem libs, such as this one: [pmem
java|https://github.com/pmem/llpl],
These libraries are for guaranteeing the persistence nature in the underlying
devices after power cycles. We are not trying to have a persistent based cache
where we need to regain the data back after a restart. The llpl library that
you pointed is a Java wrapper on
[http://pmem.io/.|http://pmem.io/]
This native library assures durability by memory mapping the file on the Pmem
device.
See the notes here
{code:java}
The Persistent Memory Development Kit, PMDK, is a growing collection of
libraries which have been developed for various use cases, tuned, validated to
production quality, and thoroughly documented. These libraries build on the
Direct Access (DAX) feature available in both Linux and Windows, which allows
applications direct load/store access to persistent memory by memory-mapping
files on a persistent memory aware file system.{code}
So Java's memory mapping itself allows us to get that capability.
If we want the persistence nature of the cache then yes we need to go with LLPL
library but that can be taken as next step.
> Bucket cache on Persistent memory
> ---------------------------------
>
> Key: HBASE-21874
> URL: https://issues.apache.org/jira/browse/HBASE-21874
> Project: HBase
> Issue Type: New Feature
> Components: BucketCache
> Affects Versions: 3.0.0
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-21874.patch, HBASE-21874.patch, Pmem_BC.png
>
>
> Non volatile persistent memory devices are byte addressable like DRAM (for
> eg. Intel DCPMM). Bucket cache implementation can take advantage of this new
> memory type and can make use of the existing offheap data structures to serve
> data directly from this memory area without having to bring the data to
> onheap.
> The patch is a new IOEngine implementation that works with the persistent
> memory.
> Note : Here we don't make use of the persistence nature of the device and
> just make use of the big memory it provides.
> Performance numbers to follow.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
