InK: In-Kernel Key-Value Storage with Persistent Memory

Round 1

Reviewer 1 Report

The authors have reported novel work on Ink based design in persistent memory. This is useful work. They found that Ink-based design is the best than RocksDB No DAX and RocksDB DAX. They found that Ink persistent is stable. This is timely and useful work. However, my minor suggestions are below.

1. In Fig. 7, the authors should explain what is latency breakdown? It will be easier for broad readers.
2. It is realized that Ink-based design is useful in between volatile and non-volatile memory. It is suggested that the authors should include some recent references (https://doi.org/10.1002/aelm.202000209;DOI: 10.1109/LED.2020.2980625) on non-volatile memory. It may be useful like neuromorphic computing at low power.
3. In Fig. 10 and 11, the authors should mention the colors in writing and it will be easier for readers to see data in the figures. There are some variations of data in RocksDB. They should explain. They should explain the limitation of Ink-based design in PM. It may be slow to transfer data from volatile to non-volatile.
4. The authors should write clearly their contribution in this paper at the end of introduction part.

Author Response

Please see the attachment

Author Response File: Author Response.pdf

Reviewer 2 Report

In order to correctly evaluate the relevance of the authors' proposal, the results and comparisons must be expanded, and thus the proposal will be correctly characterized:

 

1. The authors detect a weak point in their proposal (write operations), nothing to object to, but then only workloads are analyzed that avoid the detected weak point, this no longer seems correct, it is necessary to know the impact of this weak point.
2. The comparisons presented are made only with respect to RocksDB, but there are other proposals, in fact some are referenced in the article ([18] and [19]), in addition to Intel's proposal ([27]), these works cannot be ignored.
3. The authors only use in the comparisons an order equal to 63, since with that value they get their best results, and nothing is said about RocksDB.

 

It is not correct to say "we believe the scattered chunks can be easily defragmented when the system is idle", without justifying such a sentence.

 

In the data tables "search" is used some times and "read" others, please clarify.

 

Figure 7 (a) is missing.

 

Some typos in lines: 68, 69, 112, 287, 392, 532 and 535.

Author Response

Please see the attachment

Author Response File: Author Response.pdf

Round 2

Reviewer 2 Report

The answer given by the authors to all my concerns, seems to me to be correct and adequate and the article has been slightly improved. However, I have not been able to detect that the answer to point 3 is reflected in the new version of the article. I consider that it should have been and I suggest the authors to do so.

Author Response

Please see the attachment

 

Author Response File: Author Response.pdf