Re: Adding PM QoS parameters

[mark gross <mgross@linux.intel.com>]

On Tue, Apr 14, 2009 at 12:24:20PM +0000, Patrick Bellasi wrote:
> mark gross <mgross <at> linux.intel.com> writes:
>  
> > I can see that more parameters would make sense.  Can you come up with
> > a set of abstractions that have a chance of being portable?
> 
> Hi,
>    we are a group that since some months is working on "Constrained Power
> Management" in STMicroelectronics. 

I would like to hear what your ideas are around applying constraints to
power management!  The notion of constraint based PM has been rattling
around, in my head and elsewhere, for a while now (a couple of years).
PMQoS is just an early application of it.  I think a lot more could be
done in this area.

Recently I've been thinking about re-factoring PMQoS in possibly crazy
ways with the goal of somehow supporting a more generic constraint
notion without making the PMQoS ABI into a free for all.
 
> > > [sp] Here is rough outline
> > > 
> > >      Initialize the QoS array (with room to extend) as:
> > > 
> > >     static struct pm_qos_object *pm_qos_array[] = {
> > >         &null_pm_qos,
> > >         &cpu_dma_pm_qos,
> > >         &network_lat_pm_qos,
> > >         &network_throughput_pm_qos
> > >         &null_pm_qos,
> > >         &null_pm_qos,
> > >         &null_pm_qos,
> > >         &null_pm_qos,
> > >         &null_pm_qos,
> > >     };
> > > 
> > >      Assuming there is an API to add objects to this array, one
> > >      could define additional param as:
> > >
> > 
> > nah, If this is where we need to go, then I would change the array to a
> > list and make it possible to add new parameters at runtime.
> > 
> > Note: this is how I originally implemented it but changed it to a
> > compile time array to force LKML review of new parameters.  The worry
> > was that driver writers would just add whatever qos param they wanted
> > and we would loose on a consistent or stable ABI the user mode clients
> > of the interface could expect.
> 
> I think that a good trade-off between "LKML control on new parameters" and
> "platform extensibility" is hard to identify if we don't refine the concept of
> QoS parameters first.
> The QoS params defined by pm_qos should avoid to be not-sufficiently general,
> to be really useful to applications, but also avoid to be too much abstract to
> support platform-specific capabilities.
> Since anyway the core pm_qos implementation is sufficiently general to handle
> both abstract and platform-specific params, maybe we should better distinguish
> among "abstract qos parameters" (AQP) and "platform-specific qos parameters"
> PQP).
> 
> AQP should be intended to be used by applications to assert abstract
> requirements on system behaviors, while PQP can be added by platform code in
> order to enable the "constrained power management paradigm" for
> architecture/board specific devices.

Maybe.
 
> In this hypothesis the better solution would be to use a dynamic data structure
> that will be initialized by the core itself to contain just the set of AQP that
> has been reviewed and approved by LKML.
> Platform code will then have the chance to add its own specific parameters too.
> 
> Moreover we could imagine that AQP will be exported to user-land, in order to
> be asserted by application software, while PQP may be hidden within the core
> and accessible only by platform drivers.
> 

I don't know if we can keep any PQP interfaces kernel only.  Policy
managers really like to run in user mode, even if its just to set the
constraints.

> 
> > Can we identify something that maps to voltage level that would have a
> > chance at being portable to non-omap?  Higher level abstractions are
> > more attractive.
> 
> I agree: user-land accessible params should be platform-independent and define
> a portable API for applications.
> This requires also to have sufficiently abstract parameters: e.g. network
> bandwidth can be easily asserted by an application while cpu-dma-latency is
> perhaps too difficult to identify at application level.

DMA latency is a somewhat sucky name for constraining CPU Idle /
C-states, but I can't think of a better name.

> 
> > I'm having conflicting feelings on voltage as a QoS quantity, but I
> > totally see the utility of using the PM-QOS infrastructure to provide a
> > constraint framework on power domains. We may need to investigate this
> > more.
> 
> In the view I've depicted before: voltages can be eventually defined as PQP
> and be used only by platform device drivers while being hidden to userspace.
> In this case they could still exploit pm_qos core capabilities.

True, but Voltage isn't actually a QoS parameter. Where it is set
certainly effects QoS but its units are all wrong for QoS, and some
other constraint mechanism (perhaps platform specific) may be needed.  
 
> > Right now adding new parameters is easy (other than dealing with LKML
> > questioning your choices for names and meanings)  To me you bring up 2
> > issues:
> > 
> > 1) adding a voltage pm-qos parameter for omap power domains
> 
> In my opinion this is reasonable only if we keep PQP (Platform-specific QoS
> Parameters) hidden from userspace by distinguishing them from AQP (Abstract
> QoS Parameters) which instead are sufficiently general and community approved.

As I type this reply I'm thinking an ok way could be to re-factor PMQoS
into a constraint framework that exposes platform specific constraint
ABI's (in some TBD sane manner---somehow), and set PMQoS on top of this
keeping same ABI and KABI's stable.

I could use some input on the way folks anticipate a constraint
infrastructure to be used.  How hot could the code paths be?  How complex
could the dependencies and inter dependencies become?  

Am I thinking about taking a walk on a slippery slope?
 
> > 2) is it the right thing to keep pm-qos-params a compile time array and
> > control the growth of the ABI via these mailing lists or make it a list
> > and enable driver creation of new parameters as they wish.
> 
> In my opinion a mixed approach, using a dynamic data structure, could be more
> interesting to target both requirements.
> 
> > Both are good things for us to discuss on the list.
> 
> We are tuned on this thread and happy to contribute to the discussion.

very cool.

--mgross

> 
> Best regards,
> Patrick
> 
> -- 
> #include <best/regards.h>
> 
> DERKLING
> 
> <-------------------------------------------------------------------------->
>   Patrick Bellasi <bellasi at elet dot polimi dot it>
>   PhD student at Politecnico di Milano
>  
>   Privacy:
>    - GnuPG     0x72ABC1EE (keyserver.linux.it)
>       pub      1024D/72ABC1EE 2003-12-04
>       Key fingerprint = 3958 7B5F 36EC D1F8 C752
>                                9589 C3B7 FD49 72AB C1EE
> <-------------------------------------------------------------------------->
> 
> 
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm