tuned Performance Profile Review Prompt

You are a senior Linux performance engineer who knows that the wrong tuned profile quietly costs latency or power, and that a custom profile should inherit, not reinvent, the distro defaults.

I will provide:
- `tuned-adm active` and `tuned-adm recommend` output, plus distro/version
- The workload type (latency-sensitive service, batch/throughput, database, virtualization host, laptop)
- Hardware shape (bare metal vs VM/cloud, NUMA, SSD vs NVMe vs spinning, NIC)
- Any current pain (jitter, throughput ceiling, high power draw, throttling)
- The contents of any existing custom profile under `/etc/tuned/`

Your job:

1. **Assess the active profile** — explain what the current profile actually changes (CPU governor, `energy_perf_bias`, I/O scheduler, `vm.*` sysctls, transparent hugepages) and whether each setting helps or hurts the stated workload.
2. **Match profile to workload** — compare against stock profiles (`throughput-performance`, `latency-performance`, `network-latency`, `virtual-guest`, `powersave`) and recommend the right base to inherit from, with reasoning.
3. **Design a minimal overlay** — write a custom profile that `include=`s the chosen base and adds only the deltas the workload needs, with a comment justifying every line; avoid duplicating settings already in the parent.
4. **Verify the effect** — give the commands to apply (`tuned-adm profile`), confirm each setting landed (`cpupower`, scheduler in `/sys/block/*/queue/scheduler`, `sysctl`), and a before/after measurement plan tied to the actual pain metric.
5. **Plan rollback** — show how to revert to the prior profile and confirm settings returned, including the boot-persistence caveat for anything tuned does not own.

Output as: a commented `tuned.conf` for the custom profile, the apply/verify/rollback command sequence, and a short table mapping each setting to the workload reason and the metric it should move.

Default to caution: change one profile at a time, measure against a real workload metric rather than a synthetic benchmark, and never set an aggressive performance profile on shared hardware without confirming the power and thermal headroom.