Blog

This study is part of our paper “TOTO: Transparent I/O Tuning for HPC Applications”, accepted at ICS 2026 (International Conference on Supercomputing, Belfast, July 2026). The overhead measurements below were produced with IOPS.

When you intercept I/O system calls to analyze application behavior, how much overhead do you actually add? That’s the question we needed to answer for TOTO (Transparent and Online Tool for I/O), a library that hooks into I/O calls via LD_PRELOAD to provide runtime analysis of parallel file system access patterns.

Grid'5000 is a large-scale and flexible testbed for experiment-driven research in all areas of computer science, with a focus on parallel and distributed computing, including Cloud, HPC, Big Data and AI.

On Grid'5000 platform the reservation of computing nodes and scheduling of batch jobs is managed by the OAR software suite, while IOPS is only supporting Slurm as a batch scheduler. Thankfully, the high level of similarity between OAR and Slurm (at least from a user perspective) makes it easy to run IOPS on Grid'5000 front-end with OAR being used to schedule & control the test jobs on the computing nodes. Let’s see how…

IOPS can use Bayesian Optimization when the objective is to find the parameter combination that yields the maximum (or minimum) metric value in a search space. In this article, we decided to test the efficiency of IOPS’s BO search by comparing it against IOPS’s random search. The idea is simple: given a search space, run both IOPS BO and Random, then compare the results to see which one reaches the optimal first. And of course, it should not be a surprise at this point that we used an I/O benchmark to do it.