"CPU idle states and plugin hosting: what holding cpu_dma_latency buys"

The question

The host library can hold /dev/cpu_dma_latency while it runs, which tells the kernel not to put any core in an idle state whose exit takes longer than the value. The same plugins were run through mod-host, omx-clap-host (CLAP and the LV2 adapter), the in-process tier, plugin-hostd and jalv, with the device held at nothing, at 10 µs (C1 only, the shipped default) and at 0 (no idle state).

"Off" is the machine at rest: its tuned profile held the device at 4000 µs, which refuses no state (C3 exits in 1048 µs). The three holds interleaved per repetition, so a drift of the machine over the hour does not line up with one hold. The CLAP rows carry seven plugins, the LV2 rows eight.

The machine

Intel Core Ultra 9 275HX (8 performance and 16 efficiency cores, 24 threads), the performance governor, intel_idle with the menu governor, states POLL, C1 (1 µs), C2 (127 µs) and C3 (1048 µs), all enabled. Watts are the package's RAPL counter, integrated over each run's 30 s window. Another real-time audio graph ran on the same machine and is inside every watt figure: only the differences between holds mean anything, not the level.

The whole graph

Cycle end is the driver's time from wake-up to the last node finished; overruns are cycles that ended past their period. 96 kHz, 128 frames (period 1333 µs), median of three repetitions:

At 48 kHz and 128 frames the story is the same with higher numbers: 243 to 439 µs at rest, 80 to 118 at 10 and 26 to 49 at 0, and no path overran in any hold.

What it says

• The hold at 10 µs cuts the cycle end three to five times on every path, and mod-host's lead is gone. With the hold off, mod-host and plugin-hostd end their cycles at 224 to 235 µs, where omx-clap-host and the in-process tier take 324 to 392. At 10 every path sits between 72 and 103 µs; at 0 between 26 and 43. mod-host's advantage at rest was the cores its extra clients kept awake; once no core sleeps past C1 the hosts are equal for one plugin set. The two CLAP rows stay about 30 µs above the LV2 rows at every hold: that is the CLAP paths' own cost, not an idle effect.
• Overruns go with it: 14 to 39 per 30 s with the hold off at 96 kHz, 0 or 1 at 10.
• 10 µs costs one to four watts; 0 costs sixty. At 96 kHz the hold at 10 reads 1.2 to 2.2 W more than rest on most paths; at 48 kHz 1.6 to 3.7 W more, since the cores have twice as long to sleep between cycles there. The hold at 0 refuses even C1, so every thread polls between cycles: 58 to 64 W more, four times the package power, for a further 45 to 60 µs of cycle end. So 10 µs is the default, and 0 only an explicit choice.
• Host CPU is clock time, so it falls as cycles shorten; it is not the host working less.
• Memory does not move with the hold. Between paths: in-process LV2 25 MiB, the adapter 29, mod-host and the CLAP rows 41 to 43, plugin-hostd 91 (the daemon and its worker), jalv 109 for eight processes.

Per plugin

The node's own time per cycle (the plugin plus what its host does inside the node's cycle), 96 kHz, 128 frames, median of three repetitions, µs, hold off / 10 / 0:

• Across hosts, at one hold, a plugin costs the same within one or two microseconds. The in-process rows read one to three microseconds higher on the light plugins: the per-block guards the in-process tier runs (a clamp and a non-finite scan), which the socket hosts do not.
• The hold's effect per node is not monotonic. From rest to 10 the light plugins get faster but the heavy ones slower, on every host alike: one compressor from about 10 to 17 µs, a reverb from 28 to 50. At 0 everything is fastest. The whole graph still gains at 10, because the idle-state exit it removes is hundreds of microseconds.

Two checks were made for that slowdown, and neither explains it. Core placement: the host's real-time threads sat on performance cores 65 % of the time at rest, 77 % at 10 and 61 % at 0, so the slowest hold had the most performance-core time. Clocks: the uncore held its maximum under every hold, and the cores read 3.8 to 4.6 GHz at rest and at 10. So a reverb or a look-ahead compressor runs slower per cycle with every core halted in C1, on every host, and this run does not say why. The whole-graph gain stands over it by an order of magnitude.

jalv, as Zynthian runs a layer

One jalv -i process per plugin, eight processes, the LV2 build of the same set:

• Eight processes cost the same cycle as one. With the hold at 10, jalv ends the cycle at 72 µs against 72 to 74 for mod-host and the adapter in one process; at 0, 26 against 26 to 27.
• They cost memory and a little power: 109 MiB for eight jalv processes against 29 to 41 for one process holding the same plugins.
• jalv's probe cycles arrive late more often at every hold, though its node times per plugin are everyone's.
• A plugin GUI shown on a virtual X server changes the cycle by nothing and costs 94 MiB and about a watt.

Caveats

One machine, one plugin set, 30 s windows, three repetitions. The in-process rows are the bench's own small host making the same library calls as the console's tier, not the console itself.