[FAST'26] Cylon Artifact Evaluation

• The artifact consists of these 3 components.
  • CylonFEMU: Cylon's FEMU extension codebase
  • CylonLinux: Cylon's custom kernel for DER support
  • Cylon-scripts: Benchmark and plot scripts

How to Use Cylon CXL-SSD and Reproduce Experiments

Setting up the guest image

The guest VM image must have a CXL-enabled kernel and required tools installed before use. See docs/guest-image-setup.md for the full setup guide, which covers:

• Ubuntu 22.04 base image preparation and disk resize
• Serial console GRUB configuration
• Building and installing a CXL-enabled Linux 6.4.6 kernel
• Installing ndctl

Setting up the backend memory

See docs/backend-memory-setup.md for instructions on reserving a contiguous physical memory region on the host using the memmap GRUB parameter.

Host kernel for FEMU der=cylon

FEMU's femu-cxl-ssd device with der=cylon needs the CylonLinux kernel of this repository on the host. See docs/femu-host-kernel.md for the commit to build, the host and VM requirements, the two versions of the fault exit, and the FEMU properties.

Launching the Cylon VM

1. SSH into the CloudLab host machine.

2. Start the Cylon VM:

   cd Cylon/build-femu
   ./run-cxlssh.sh

3. Pin CPUs (run in a separate terminal):

   • Make sure the CPU IDs in pin.sh are on the same NUMA node as the reserved memory.

   cd Cylon/build-femu
   ./pin.sh

4. Initializing CXL-SSD Inside the VM

• Once the VM is running, initialize the CXL-SSD device inside the guest VM:
  • Copy tools/* into the guest

  bash ~/login.sh #ssh into the VM
  ./setup_dev.sh [system_ram|devdax]

• After initialization, the CXL-SSD appears as a CPU-less NUMA node:

  numactl -H
  # available: 2 nodes (0-1)
  # node 0 cpus: 0 1 2 3 4 5 6 7
  # node 0 size: 15991 MB
  # node 0 free: 7156 MB
  # node 1 cpus:
  # node 1 size: 65536 MB
  # node 1 free: 65536 MB
  # node distances:
  # node   0   1
  # 0:  10  20
  # 1:  20  10

• Or you can expose Cylon as an devdax device.

  # devdax mode
  daxctl reconfigure-device --mode=devdax --force dax0.0
  
  # systam-ram mode (CPU-less NUMA node)
  daxctl reconfigure-device --mode=system-ram --force dax0.0

Configuring Cylon

• You can adjust Cylon configuration in build-femu/run-cxlssd.sh file.

Caching policy

# CXL-SSD DRAM buffer parameters
policy=2 # Replacement policy [1:LIFO 2:FIFO 3:S3FIFO 4:CLOCK]
prf_dg=0 # Next-n Prefetch degree

ssd_size=$1		# in MegaBytes
bufsz=$((ssd_size/20))

Logs

Buffer statistics (cxl read-labels mem0 -s 1) and per-access I/O logs are written under log_dir (LOG_DIR in run-cxlssd.sh, default ./cxlssd-logs). If the directory cannot be created, QEMU keeps running and prints the statistics to stderr.

NAND timing

# Latency in nanoseconds
pg_rd_lat=40000      # NAND Read Latency (40us)
pg_wr_lat=200000     # NAND Write (program) Latency (200us)
blk_er_lat=2000000   # NAND Erase Latency (2ms)
ch_xfer_lat=0

Reproducing Experiments

For reproducing experiments, please refer:

• Intel MLC (Figure 2, 4)
• Mio (Figure 3, 6, 9, 10)
• Redis (Figure 7, 11, 12)
• GAPBS (Figure 8)

Which mode should I use for each benchmark?

Cylon can be exposed to the guest OS in two mutually exclusive modes:

• system-ram: the CXL-SSD capacity is hot-plugged into the Linux memory subsystem and shows up as a CPU-less NUMA node. Applications use it through normal malloc()/anonymous memory (often with numactl --membind=<node>).

• devdax: the capacity is exposed as a DAX character device (e.g., /dev/dax0.0). Applications must explicitly mmap() the DAX device (or use a PMem/DAX-aware library). It is not part of the normal page allocator.

  Benchmark	Required mode
  Intel-MLC	system-ram
  MIO	devdax
  Redis YCSB	system-ram
  GAPBS	system-ram

Rule of thumb: if the benchmark/application is unmodified and uses malloc() + numactl, you want system-ram. Use devdax only for benchmarks that explicitly open/mmap /dev/dax*.

Support

If you encounter issues not covered in this document, please use GitHub Issues.