Messages in this thread | | | Date | Wed, 27 Nov 2013 08:47:32 -0800 | From | jacob pan <> | Subject | Re: [PATCH 0/3] Hook up powerclamp with PM QOS and cpuidle |
| |
On Wed, 27 Nov 2013 12:56:34 +0100 Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, Nov 26, 2013 at 03:20:08PM -0800, Jacob Pan wrote: > > This patchset is intended to address the behavior change and > > efficiency loss introduced by using consolidated idle routine in > > powerclamp driver. > > > > Specifically, > > [PATCH 3/8] idle, thermal, acpi: Remove home grown idle > > implementations > > > > The motivation is that after using common idle routine, powerclamp > > driver can no longer pick the deepest idle state needed to conserve > > power. Idle state is selected by governors which can be influenced > > by PM QOS and other factors. This patchset hooks up powerclamp idle > > injection with PM QOS and eventually influce idle governors to pick > > the power saving target states. > > > > There are some downside of this approach. Due to overhead, > > communication with PM QOS is at enable/disable idle injection time > > instead of each injection period. The implication is that if the > > system natual idle is more than target injected idle, powerclamp > > will skip some injection period. During this period however, > > deepest idle state may still be chosen necessarily regardless the > > latency constraint. > > Does the QoS stuff have a means of notifying its users of constraints > violation? I suspect some applications might light to be told if their > requests aren't honoured. > Each class has a notifier. This patchset is calling the notifier when the qos class is disable/enable. the receiver of these notifications are in the kernel.
I don't see the qos core code has a way to signal userspace about target change.
| |