Re: [PATCH RFC v3 2/3] KVM: x86: add KVM_CAP_CSTATE_POLICY for per-VM C-state enforcement

[Paolo Bonzini]

Il lun 14 set 2026, 17:24 Sean Christopherson <seanjc@xxxxxxxxxx> ha scritto:
>
> +      Option B: Use forced_idle_latency_limit_ns on the pCPU.
> +      Same per-CPU limitation, and latency-based rather than
> +      state-index-based — less precise.
>
> Conceptually, (b) seems like the right approach.  Per-task will be a mess because
> similar to a KVM-based interface, it can probably only work if tasks are pinned
> to pCPUs.


Yes, per-task (option C) doesn't make much sense. If you want to bound
the tasks' wake-up latency they're either pinned, or all I/O bound.
But if they are I/O bound and happen to contend, what happens if they
migrate? The destination pCPU won't have the right limit set, so
you're back to pCPU limits.

And doing it in KVM doesn't remove the issue.

> And isn't abstracting away the exact C-state via forced_idle_latency_limit_ns a
> *good* thing?  Without that, userspace will need to tune its configuration for
> each individual uarch based on the properties of various C-states for a given CPU.


Yes, even if you had a KVM interface it should allow nanosecond setup,
C-state indices really don't mean much.

Paolo

> +      Option C: Propose a new cpuidle API for per-task idle
> +      constraints (e.g. a per-task_struct annotation checked by
> +      the governor during select()). Correct for all cases, but
> +      bigger scope and needs cpuidle maintainer buy-in.
>