Bug 2118786

Description of request:

In TuneD today, a user can set a desired c-state system-wide via the "force_latency=cstate..." mechanism.  

There is an interest in having TuneD also support using the pm_qos_resume_latency_us interface to set c-state latency values on specific cpus.  This grew out of the "cpu power-performance" discussions of late.

With pm_qos_resume_latency_us, the c-states allowed for each CPU can be controlled with:
/sys/devices/system/cpu/cpu<c>/power/pm_qos_resume_latency_us

The value can be set to:
- "n/a": special value that disables c-states completely
- "0": allows all c-states
- "x": allows any c-state with a resume latency less than x

There are a couple of benefits of using pm_qos_resume_latency_us this way:

1. Required latency values can be set on individual CPUs.  

2) Hardware Cstate number independence:  
Because different servers support different numbers of c-states (often with different latency values in them), the use of pm_qos_resume_latency_us makes it easier for the user to simply request a desired latency value.  

This frees the user of having to worry about which c-state number a given latency maps to on any individual cpu.  


Additional info:
[1] See https://static.lwn.net/kerneldoc/admin-guide/pm/cpuidle.html#power-management-quality-of-service-for-cpus