Welcome. I'm Steve Scargall from Intel. In this video, I present an introduction to the persistent memory engines included in the popular open source Flexible I/O Tester, or FIO for short. These engines are useful for developers needing to perform benchmarks. Keep watching for some helpful information that you can use to get started.
[MUSIC PLAYING]
FIO is a popular cross-platform benchmark utility originally written by Jens Axboe, and it's still maintained by him. Prebuilt packages are available for Windows, BSD, and many Linux distributions. Linux users can find the FIO package in the package repository, and can install it using the package commands such as apt-get, yum, RPM, or DNF, followed by the package name of FIO. Alternatively, you can download source code and compile FIO yourself. The source code and instructions are available on the GitHub repository.

FIO provides many different engines, which makes it flexible and highly configurable. Each engine defines how an FIO job issues I/O operations against the target files or devices. To get a list of available engines for your operating system, run FIO dash dash enghelp. A complete list of FIO engines can be found in the I/O Engine section of the documentation. Each engine has its own configuration options, in addition to the options provided by the framework itself. Review the engine-specific documentation for the engine you want to use.
Arguments can be passed via the command line or job files. Job files are text files to provide configuration options to FIO, and remove the need to type very long command lines each time. Of particular interest to the system memory developers or those engines designed specifically for this technology. This includes mmap, pmemblk, libpmem, and dev-dax. The last three on the list use PMDK. PMDK. delivers several user libraries designed to make developing persistent memory applications much easier. More information about the PMDK libraries can be found on pmem.io and the Intel Developer Zone.
The mmap engine maps a file and then performs I/O using the memcpy system call. The pmemblk engine uses the PMDK libpmemblk library to perform atomic block-sized I/O operations on the memory map files within a filesystem mounted with the DAX option. DAX is an acronym for direct access, which is the feature on Linux that implements the SNIA non-volatile memory programming model. SBIA is the Storage Network Industry Association. The term DAX is used by both Linux and Windows to indicate an I/O path to the persistent memory devices that bypass the page cache. When a DAX file is memory mapped, the application gets direct load/store access without any kernel involvement. File systems with DAX support are commonly referred to filesystem DAX, or FSDAX for short.
The libpmem engine performs byte-addressable read/write operations to a memory map file on an FSDAX file system using the low-level libpmem library from the PMDK. The dev-dax engine uses the libpmem library to perform byte-addressable load/store operations to a device-dax instance. A device-dax, or devdax for short, provides a memory-mapped character device interface to the persistent memory devices, so it doesn't require a filesystem. FSDAX and devdax devices are created and administered using the open source ndctl utility, which is available on the pmem.io website. The ndctl user guide can be found over on docs.pmem.io. The user guides include plenty of examples to help you get started.
Example job files for each engine can be found in the FIO examples directory on GitHub. Since each system under test will have a different configuration, the example job files require only minor modification to specify the correct file, directory, or device against which the test or tests will be performed. The example job falls provide a solid foundation for customizing to suit the workload of the application. Multiple tests can be defined within a single job file, or you can specify multiple job files.
Running FIO is normally the easiest part. You just give it a job file or job files as parameters, and it will start doing what the job tells it to do. Each test will produce an output to the terminal showing IOPS, latency, bandwidth, and throughput. The output can additionally be written to log files, which makes it easier to graph and compare different test results.
Thanks for watching. If you'd like to learn more about FIO and the persistent memory engines, please follow the links provided and subscribe to our channel.