[ioquatix]

Run the hello benchmark's raw-closed and http-closed client with two workers, and document hana, the measuring host, in a new benchmarks/hosts/hana.md, whose placement for the closed loop is --role-cpus client=1,2 --role-cpus server=3. The evidence is a screen on hana, recorded in benchmarks/hello/results/client-layout-20261109.

A review found raw-closed limited by its one client worker, and it was proposed to run two workers on the two hyperthreads of one core. The screen compared, with the server on CPU 3 and the scenarios' measured arguments, one worker on CPU 1 (A), two workers on CPU 1 and its sibling 5 (B), and two workers on CPUs 1 and 2, two cores (C), each pinned with the controller on CPU 0, and B and C again with the workers and controller unpinned within the client's CPUs, as --role-cpus places them (B-u, C-u). It covered base-native-raw and base-iouring-raw in raw-closed, base-native and hyper-tokio in http-closed, and the server on 2,3 and 2,3,6,7 under A. It ran six shuffled rounds under the host lock, with server CPU from /proc over the client's window, and a supplementary campaign of six rounds with CPU frequencies and the server on 3,7.

Scenario	Backend	A	B	C	C-u	Busy (A / B / C)
raw-closed	base-native-raw	240,353 (−5.8%)	255,474 (+0.4%)	254,649	254,649 (−0.1%)	1.00 / 0.99 / 0.67
raw-closed	base-iouring-raw	240,355 (−5.3%)	257,585 (+0.9%)	254,059	255,592 (+0.5%)	1.00 / 1.00 / 0.66
http-closed	base-native	204,909 (−1.4%)	212,486 (+1.8%)	209,814	209,272 (+0.6%)	0.97 / 0.90 / 0.55
http-closed	hyper-tokio	194,532 (−0.2%)	195,779 (+1.0%)	194,276	194,961 (−0.4%)	0.96 / 0.85 / 0.51

Requests per second are medians of six rounds; percentages are the median per-round ratio to C. No sample had an error or an invalid response.

• One worker limits raw-closed by 5–6% and is busy for 96–98% of the window in http-closed, so the client flags itself as saturated in both.
• Two workers on one core's siblings match two cores in raw-closed, but only with both threads saturated, leaving no headroom for a faster raw control. In http-closed they were 1–2% faster, but flagged as saturated, with the server spending up to 2.8% less CPU per request at the same frequency (about 4.0 GHz on CPU 3 in both layouts). The siblings' contention also doubles the client's dispatch lag p99 (0.7–0.8 µs to 1.1–1.3 µs) and raises its CPUs' softirq time per request by 53–73%.
• Two cores leave each worker busy for two-thirds of the window in raw-closed and half in http-closed, with CVs of 0.3–1.4%, except base-native in http-closed under pinned C (2.4–4.0%, from one or two low rounds); C-u had 1.0% there. Unpinned within --role-cpus client=1,2 matched pinned within 0.6%.
• The server's sibling (3,7) did not help a single-threaded backend (−0.6%). The server on 2,3 or 2,3,6,7 under A, with the client saturated, was inconclusive: +3.2% and +1.8% by median, but rounds ranged from −8.8% to +9.1%.

The fixed-rate scenarios keep one worker, as the screen did not measure them. Their placement in hana.md is the one the readme suggested before, client=1,5 server=2,3, marked as unmeasured.

As the maintainer asked, hana's hardware and placement leave benchmarks/hello/readme.md for benchmarks/hosts/hana.md. It records the CPU, SMT layout, caches, frequencies, scaling driver, governor and energy preference, memory, NUMA, kernel and distribution, mitigations, the NIC interrupt placement and loopback settings, the kinds of services sharing the host, the Rust toolchain, the CPU partitioning and the read-only commands that gathered it. benchmarks/hosts/readme.md says each host gets one such document. hana-linux.md is an investigation rather than a host description, so hana.md links to it and the other earlier placements.

This is screening evidence: one host, one day and six rounds, run by the recorded layout.py rather than by base-benchmark, on a host shared with light services.