[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080627071948.GA15424@dirshya.in.ibm.com>
Date: Fri, 27 Jun 2008 12:49:48 +0530
From: Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>
To: Andi Kleen <andi@...stfloor.org>
Cc: balbir@...ux.vnet.ibm.com,
Linux Kernel <linux-kernel@...r.kernel.org>,
Suresh B Siddha <suresh.b.siddha@...el.com>,
Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Dipankar Sarma <dipankar@...ibm.com>,
Vatsa <vatsa@...ux.vnet.ibm.com>,
Gautham R Shenoy <ego@...ibm.com>
Subject: Re: [RFC v1] Tunable sched_mc_power_savings=n
* Andi Kleen <andi@...stfloor.org> [2008-06-26 22:17:00]:
> Vaidyanathan Srinivasan wrote:
>
> Playing devil's advocate here.
>
[...]
> > The
> > power QoS framework set_acceptable_latency() ensures that the lowest
> > latency set across the system wins.
>
> But that only helps kernel drivers, not user space, doesn't it?
Yes the QoS notification is mainly for kernel drivers, but
applications can control them using the /dev/[...,network_latency,...]
interface as documented in Documentations/power/pm_qos_interface.txt
The device drivers are expected to get feedback (tunable?) from
applications that are dependent on those drivers and set the correct
power saving level. Multimedia applications are expected to make use
of this interface to set/communicate the correct power saving levels
for audio drivers.
Many application can set different latency requirement, but the least
will win. Here the PM-QoS framework in kernel arbitrates between
applications and resolves conflicts by choosing the least latency or
most conservative power saving mode.
--Vaidy
[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists