aerospike-SPDK patch based on 5.5.0.4 #40
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is aerospike-SPDK patch
The purpose of this patch, namely aerospike-SPDK patch, is to enable Aerospike users and developers to evaluate the merit of IO stack optimization designed for low latency SSDs, such as KIOXIA FL6. The patch is expected to reduce CPU cost for IO operations thanks to SPDK and expected to reduce CPU cost spent in pthread-switching thanks to user-level light-weight-context library, so that Aerospike users who uses low latency SSDs can get better transaction performance per server and better latency.
Main changes
(1) We abstract io-operations, such as pread/pwrite, in order to support other io methods, in order to support SPDK, a high-performance user-level-IO library, and implement SPDK-IO-backend. Since SPDK employs user-level asynchronous IO scheme, (2) we also abstract the thread layer, in order to support user-level context switching, and we implement Lthread backend. User-level context switching contributes to reducing context switching cost, but it often not compatible with blocking operations, such as blocking-io operations and resource locking operation like pthread_mutex_lock. In order to enable resource-locking on top of user-level context switching, (3) we also implement non-blocking version of mutex_lock, by using try_lock and yield.
Known problems
Best Regards,