Part 4: DPAS Lab

Prerequisites

You must have already completed the platform-specific QEMU installation and Ubuntu VM setup.

• macOS Setup Guide
• Linux Setup Guide
• Windows Setup Guide

Part 1: DPAS Kernel Installation

Install the DPAS-patched kernel using the provided deb packages.

1-1. Transfer Packages

Transfer the downloaded deb files from the host to the VM.

# Run on the host terminal
scp -P 2222 linux-image-5.18.0-dpas_*.deb <username>@localhost:~/
scp -P 2222 linux-headers-5.18.0-dpas_*.deb <username>@localhost:~/

1-2. Install and Reboot

# Run inside the VM
sudo dpkg -i ~/linux-image-5.18.0-dpas_*.deb ~/linux-headers-5.18.0-dpas_*.deb
sudo reboot

1-3. Verify Installation

uname -r
# 5.18.0-dpas

Part 2: Lab — Performance Comparison by Mode

2-1. Benchmark Script

Use the unified benchmark script bench.sh. It selectively runs 5 I/O completion modes and measures IOPS, latency, CPU usage, and context switches for each mode across job counts (1,2,4,8,16).

Download bench.sh

Supported Modes

Key Features

• Pinned to CPU 0 (taskset -c 0)
• modprobe nvme reload between each mode/job
• Per-mode NVMe loading: INT without poll_queues, others with poll_queues=jobs (capped at nproc)
• DPAS paper settings: param1=0, param2=10, param3=10, param4=1
• DPAS mode breakdown (per-mode IO counts) after each run
• Reports: IOPS, avg latency (us), CPU % (usr+sys), context switches

Usage

# Transfer to VM
scp -P 2222 bench.sh <username>@localhost:~/

# Run inside VM
chmod +x bench.sh

# Syntax: sudo bash bench.sh [modes...] [R|W] [repeat_count]
sudo bash bench.sh ALL                  # All modes, randread, 1 run
sudo bash bench.sh INT CP DPAS W 3      # 3 modes, randwrite, 3 runs
sudo bash bench.sh DPAS 2               # DPAS only, randread, 2 runs
sudo bash bench.sh ALL W 2              # All modes, randwrite, 2 runs

# Arguments can be in any order:
sudo bash bench.sh INT 2 R CP           # same as: CP INT R 2

Sample Output

=== INT ===
Jobs         IOPS       lat_us     cpu%        ctx
----       ------       ------    -----     ------
1            7253        137.3      0.2     145087
2           16294        122.2      0.8     250851
...

=== DPAS ===
Jobs         IOPS       lat_us     cpu%        ctx   breakdown
----       ------       ------    -----     ------   ----------
1           18694         53.1     94.7      18058   cp:170035 pas:17100 ol:0 int:0
2           24119         82.1      2.3     398800   cp:1000 pas:800 ol:2801 int:236614
...

2-2. Recording Results

Record the IOPS from the script output.

2-3. Verifying DPAS Mode Transition

Check the DPAS breakdown in the bench.sh output:

Expected Behavior

2-4. Analysis Questions

1. What causes the IOPS difference between INT and CP modes when j=1?
2. Why does IOPS not increase significantly when adding more jobs in CP mode? (Consider CPU usage)
3. Explain why DPAS approaches CP performance at j=1 and approaches INT performance at j≥4 from the perspective of mode transition.
4. Why is the pas io count always less than the polled io count in the DPAS breakdown?
5. Explain how the d_init value affects DPAS mode transitions.

Part 3: DPAS Kernel Internals

3-0. IO Path and DPAS Intervention Point

When fio submits IO, it traverses the kernel block layer to reach the NVMe driver. DPAS controls the completion waiting strategy in the polling path.

/* Userspace */
fio (pvsync2 --hipri)
  └─ preadv2(RWF_HIPRI)                   /* polling request flag */

/* Kernel: IO submission (block/fops.c) */
  └─ blk_mq_submit_bio()                  /* block layer entry */
       ├─ ★ INT→OL transition (int_cnt ≥ 10000) /* re-evaluate at submit */
       └─ nvme_queue_rq()                   /* dispatch to NVMe driver */

/* Kernel: IO completion wait (block/blk-mq.c) */
  └─ blk_mq_poll()                        /* polling entry point */
       └─ blk_mq_poll_hybrid()             /* ★ DPAS core: mode decision */
            ├─ blk_mq_poll_pas_nsecs()      /* adaptive sleep calc (dur, tf) */
            ├─ mode transition logic         /* CP↔PAS→OL→INT transitions */
            └─ hrtimer_nanosleep()           /* PAS: sleep then poll */
               or poll immediately (CP)
               or return → wait for interrupt (INT)

sysfs Interface

The DPAS kernel provides the following parameters under /sys/block/nvme0n1/queue/.

3-1. Core Control Logic (block/blk-mq.c)

The code below is from blk_mq_poll_hybrid(), the DPAS mode transition logic. See how each sysfs parameter controls the transitions.

① PAS Evaluation (every 100 IOs)

/* Evaluate after collecting 100 IOs in PAS mode */
if(sc->mode == _PAS && sc->pas_cnt >= 100) {
    average_qd = sc->qd_sum * 10 / sc->pas_cnt;  /* 10x precision */

    if(sc->param4 >= 1 && average_qd == 10) {  /* ← switch_param4: enable PAS→CP */
        sc->mode = _CP;          /* QD=1.0 → polling is better */

    } else if(sc->tf > sc->param1) {            /* ← switch_param1: PAS→OL threshold */
        sc->mode = _OL;          /* timer failure → overloaded */

    } else {                                  /* stay in PAS */
        sc->pas_cnt = 0;
        sc->qd_sum = 0;
        sc->tf = 0;              /* tf resets every evaluation */
    }
}

② OL Evaluation (every 100 IOs)

/* Evaluate after collecting 100 IOs in OL mode */
if(sc->mode == _OL && sc->ol_cnt >= 100) {
    average_qd = sc->qd_sum * 10 / sc->ol_cnt;

    if(average_qd <= sc->param2) {             /* ← switch_param2: OL→PAS recovery */
        sc->mode = _PAS;         /* load decreased → retry sleep */

    } else if(average_qd > sc->param3) {       /* ← switch_param3: OL→INT escalation */
        sc->mode = _INT;         /* high load → interrupt mode */

    } else {                                  /* stay in OL */
        sc->ol_cnt = 0;
        sc->qd_sum = 0;
    }
}

③ Adaptive Sleep & Timer Failure

/* sr_pnlt: previous IO was oversleep(0) / undersleep(1)
   sr_last:  current IO was oversleep(0) / undersleep(1)
   case: sr_pnlt*2 + sr_last → 0,1,2,3 */
cur_case = stat.sr_pnlt * 2 + stat.sr_last;
switch(cur_case) {
    case 0: adj -= dn;                         /* over,over → decrease sleep */
    case 1: adj = div + up;                     /* over,under → slightly increase */
    case 2: adj = div - dn;                     /* under,over → slightly decrease */
    case 3: adj += up;                          /* under,under → increase sleep */
}

stat.dur = stat.dur * adj / div;              /* update sleep duration */

if(stat.dur < q->d_init) {                   /* ← pas_d_init: minimum sleep */
    stat.dur = q->d_init;                     /* floor clamp */
    sc->tf++;                                 /* timer failure incremented! */
}                                             /* → accumulated tf triggers PAS→OL */

Part 4: Building the Kernel from Source Challenge

Instead of using deb packages, apply the DPAS patch directly to the kernel source and build it yourself.

4-1. Install Build Dependencies

sudo apt install -y build-essential libncurses-dev bison flex libssl-dev \
    libelf-dev bc pahole dwarves zstd

4-2. Download Kernel Source

cd ~
wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.18.tar.xz
tar xf linux-5.18.tar.xz
cd linux-5.18

4-3. Apply the DPAS Patch

# After transferring the patch from host to VM
patch -p1 < ~/dpas.patch

4-4. Kernel Configuration (Minimized)

cp /boot/config-$(uname -r) .config
yes '' | make localmodconfig

4-5. Build

make -j$(nproc) bindeb-pkg

Upon successful build, linux-image-*.deb and linux-headers-*.deb files will be generated in the home directory.

4-6. Install

sudo dpkg -i ~/linux-image-5.18.0-dpas_*.deb ~/linux-headers-5.18.0-dpas_*.deb
sudo reboot

Troubleshooting

Reference: Limitations of the QEMU Environment