Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Madhava Krishnan Ramanathan

dblp:217/0682 · DBLP profile ↗
← Back
7ranked-venue papers
4as first author
4since 2021 · last 2023
0000-0001-8079-4127ORCID · reported

Domains — the database's venue-derived domains; a paper can count in several

Systems, architecture and hardware · 5 · 4 first-author · 3 since 2021Software engineering, systems software and programming languages · 4 · 1 first-author · 1 since 2021Databases, data management, data science and information retrieval · 1 · 1 first-author · 1 since 2021

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Computer architecture, parallel and distributed computing, and storage systems
5 papers
Memory systems · 62% Storage systems · 16% Parallel and multicore computing · 11%
Software engineering, system software, and programming languages
1 paper
Concurrent programming · 100%
Databases, data mining, and information retrieval
2 papers
Indexing and storage engines · 82% Transaction processing and concurrency control · 18%

Topics — the 18 heaviest of 19, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Memory systems
non-volatile memory
1.022021
TIPS: Making Volatile Index Structures Persistent with DRAM-NVMM Tiering · USENIX ATC 2021
PACTree: A High Performance Persistent Range Index Using PAC Guidelines · SOSP 2021
Memory systems › non-volatile memory › persistent memory
persistent memory indexing
1.022021
TIPS: Making Volatile Index Structures Persistent with DRAM-NVMM Tiering · USENIX ATC 2021
PACTree: A High Performance Persistent Range Index Using PAC Guidelines · SOSP 2021
Memory systems › non-volatile memory
persistent memory
0.712023
TENET: Memory Safe and Fault Tolerant Persistent Transactional Memory · FAST 2023
Parallel and multicore computing
transactional memory
0.712023
TENET: Memory Safe and Fault Tolerant Persistent Transactional Memory · FAST 2023
Indexing and storage engines
range index
0.512021
PACTree: A High Performance Persistent Range Index Using PAC Guidelines · SOSP 2021
Storage systems
crash consistency
0.412020
Durable Transactional Memory Can Scale with Timestone · ASPLOS 2020
Distributed systems › concurrency control
multi-version concurrency control
0.412020
Durable Transactional Memory Can Scale with Timestone · ASPLOS 2020
Memory systems › non-volatile memory
non-volatile main memory
0.412020
Durable Transactional Memory Can Scale with Timestone · ASPLOS 2020
Memory systems › non-volatile memory › persistent memory
persistent transactional memory
0.412020
Durable Transactional Memory Can Scale with Timestone · ASPLOS 2020
Concurrent programming
multi-version execution
0.412019
MV-RLU: Scaling Read-Log-Update with Multi-Versioning · ASPLOS 2019
Concurrent programming › synchronization
read-copy-update
0.412019
MV-RLU: Scaling Read-Log-Update with Multi-Versioning · ASPLOS 2019
Concurrent programming
synchronization
0.412019
MV-RLU: Scaling Read-Log-Update with Multi-Versioning · ASPLOS 2019
Distributed systems
fault tolerance
0.212023
TENET: Memory Safe and Fault Tolerant Persistent Transactional Memory · FAST 2023
Storage systems
logging
0.112020
Durable Transactional Memory Can Scale with Timestone · ASPLOS 2020
Storage systems › flash and SSD › flash memory management › garbage collection
write amplification
0.112020
Durable Transactional Memory Can Scale with Timestone · ASPLOS 2020
Transaction processing and concurrency control
concurrency control
0.112019
MV-RLU: Scaling Read-Log-Update with Multi-Versioning · ASPLOS 2019
Storage systems › key-value storage
in-memory key-value store
0.112019
MV-RLU: Scaling Read-Log-Update with Multi-Versioning · ASPLOS 2019
Storage systems
key-value storage
0.112019
MV-RLU: Scaling Read-Log-Update with Multi-Versioning · ASPLOS 2019

Methods — techniques the papers use, named apart from their topics

software transactional memory · 1.1autonomous garbage collection · 1.1packed asynchronous concurrency · 1.0NVM-aware design · 1.0multiversioning · 0.8multi-version concurrency control · 0.4hybrid logging · 0.4multi-versioning · 0.4
YearPublicationVenuePosition
2023 TENET: Memory Safe and Fault Tolerant Persistent Transactional Memory
Madhava Krishnan Ramanathan, Diyu Zhou, Wook-Hee Kim, Sudarsun Kannan, Sanidhya Kashyap, Changwoo Min
FAST1
2023 Retina: Cross-Layered Key-Value Store for Computational Storage
abstract
We propose RETINA-a unified key-value store (KVS) with computational pipeline framework natively designed for computational storage. Retina proposes a cross-layered architecture to leverage CPU as the control plane and near-storage FPGA as the compute & data plane which is key to reducing the data movement and achieving high-performance. Retina Kvs includes near-storage Arbiter implemented on the FPGA which is capable of scheduling tasks, manage memory, and establish communication between the host CPU and the near-storage FPGA. Retina enables applications to compose and offload compute to the storage during the run time with a familiar set of KVS-style APIs. We evaluate Retina by integrating it to TensorFlow machine learning framework and training the ResNet50 DL model by offloading the entire image preprocessing steps to the near-storage FPGA. Overall, Retina performs up to 75% faster and saves up to 65% CPU time against CPU-only systems.
Madhava Krishnan Ramanathan, Naga Sanjana Bikonda, Shashwat Jain, Wook-Hee Kim, Hamid Hadian, Vishwanath Maram, Changwoo Min
MASCOTS1
2021 PACTree: A High Performance Persistent Range Index Using PAC Guidelines
abstract
Non-Volatile Memory (NVM), which provides relatively fast and byte-addressable persistence, is now commercially available. However, we cannot equate a real NVM with a slow DRAM, as it is much more complicated than we expect. In this work, we revisit and analyze both NVM and NVM-specific persistent memory indexes. We find that there is still a lot of room for improvement if we consider NVM hardware, its software stack, persistent index design, and concurrency control. Based on our analysis, we propose Packed Asynchronous Concurrency (PAC) guidelines for designing high-performance persistent index structures. The key idea behind the guidelines is to 1) access NVM hardware in a packed manner to minimize its bandwidth utilization and 2) exploit asynchronous concurrency control to decouple the long NVM latency from the critical path of the index.
Wook-Hee Kim, Madhava Krishnan Ramanathan, Xinwei Fu, Sanidhya Kashyap, Changwoo Min
SOSP2
2021 TIPS: Making Volatile Index Structures Persistent with DRAM-NVMM Tiering
Madhava Krishnan Ramanathan, Wook-Hee Kim, Xinwei Fu, Sumit K. Monga, Hee Won Lee, Minsung Jang, Ajit Mathew, Changwoo Min
USENIX ATC1
2020 Durable Transactional Memory Can Scale with Timestone
abstract
Non-volatile main memory (NVMM) technologies promise byte addressability and near-DRAM access that allows developers to build persistent applications with common load and store instructions. However, it is difficult to realize these promises because NVMM software should also provide crash consistency while providing high performance, and scalability. Durable transactional memory (DTM) systems address these challenges. However, none of them scale beyond 16 cores. The poor scalability either stems from the underlying STM layer or from employing limited write parallelism (single writer or dual version). In addition, other fundamental issues with guaranteeing crash consistency are high write amplification and memory footprint in existing approaches. To address these challenges, we propose TimeStone: a highly scalable DTM system with low write amplification and minimal memory footprint. TimeStone uses a novel multi-layered hybrid logging technique, called TOC logging, to guarantee crash consistency. Also, TimeStone further relies on Multi-Version Concurrency Control (MVCC) mechanism to achieve high scalability and to support different isolation levels on the same data set. Our evaluation of TimeStone against the state-of-the-art DTM systems shows that it significantly outperforms other systems for a wide range of workloads with varying data-set size and contention levels, up to 112 hardware threads. In addition, with our TOC logging, TimeStone achieves a write amplification of less than 1, while existing DTM systems suffer from 2×-6× overhead.
Madhava Krishnan Ramanathan, Ajit Mathew, Xinwei Fu, Anthony Demeri, Changwoo Min, Sudarsun Kannan
ASPLOS1
2020 Poseidon: Safe, Fast and Scalable Persistent Memory Allocator
abstract
Persistent memory allocator is an essential component of any Non-Volatile Main Memory (NVMM) application. A slow memory allocator can bottleneck the entire application stack, while an unsecure memory allocator can render applications inconsistent upon program bugs or system failure. Unlike DRAM-based memory allocators, it is indispensable for an NVMM allocator to guarantee its heap metadata safety from both internal and external errors. An effective NVMM memory allocator should be 1) safe, 2) scalable, and 3) high performing. Unfortunately, none of the existing persistent memory allocators achieve all three requisites. For example, we found that even Intel's de-facto NVMM allocator-libpmemobj is vulnerable to silent data corruption and persistent memory leaks resulting from a simple heap overflow.
Anthony Demeri, Wook-Hee Kim, Madhava Krishnan Ramanathan, Mohannad Ismail, Changwoo Min
Middleware3
2019 MV-RLU: Scaling Read-Log-Update with Multi-Versioning
abstract
This paper presents multi-version read-log-update (MV-RLU), an extension of the read-log-update (RLU) synchronization mechanism. While RLU has many merits including an intuitive programming model and excellent performance for read-mostly workloads, we observed that the performance of RLU significantly drops in workloads with more write operations. The core problem is that RLU manages only two versions. To overcome such limitation, we extend RLU to support multi-versioning and propose new techniques to make multi-versioning efficient. At the core of MV-RLU design is concurrent autonomous garbage collection, which prevents reclaiming invisible versions being a bottleneck, and reduces the version traversal overhead the main overhead of multi-version design. We extensively evaluate MV-RLU with the state-of-the-art synchronization mechanisms, including RCU, RLU, software transactional memory (STM), and lock-free approaches, on concurrent data structures and real-world applications (database concurrency control and in-memory key-value store). Our evaluation results show that MV-RLU significantly outperforms other techniques for a wide range of workloads with varying contention levels and data-set size.
Ajit Mathew, Sanidhya Kashyap, Madhava Krishnan Ramanathan, Changwoo Min
ASPLOS4