Real device I/O measured per page layout. Cross-check these
numbers with your own eBPF/blktrace/iostat counters.
Illustrative report — synthetic smoke data, not a DGraphFin measurement. Generated from a small synthetic community graph to demonstrate the report. Regenerate with a real run: make defconfig-gnn-dgraphfin-force-ssd && make, then make gnn-ssd-report.
fewer device reads, random → natural (neighbor RA_fetch)
10.2x–10.2x
page RA_signal range — the floor no layout closes
0.1 GB
real device reads issued across layouts
The value: locality lowers device reads
The neighbor pattern expands random training seeds to their
sampled neighborhood. A locality-aware layout (metis) keeps those neighbors
on a few 4 KiB pages, so the device serves far fewer reads per useful
byte. The measured O_DIRECT amplification tracks the in-RAM modeled metric,
which is exactly the agreement an external observer should confirm.
The gap: the supervised-read floor
The page-aligned sweep reads whole training pages. RA_fetch is
~1x for any layout, but only a fraction of nodes per page are supervised, so
RA_signal — bytes read per supervised node — cannot drop below the ~4.3x
floor no matter how good the layout is. That floor is the gap the layout work
leaves open.
All metrics
layout
nbr RA_fetch
nbr RA_signal
page RA_fetch
page RA_signal
nbr pages
nbr read ops
GB read
MB/s
O_DIRECT
natural
2.81x
94.0x
1.99x
10.2x
9,130
3,128
0.04
26
yes
random
7.06x
235.9x
1.99x
10.2x
22,926
49
0.09
76
yes
Verify it yourself
We do not run eBPF here; the harness only issues the reads.
Attach biosnoop/biolatency, blktrace
or iostat -x to the device backing the store and confirm the
per-I/O read intent and amplification independently.