On 11/12/2014 04:02 PM, Peter Zijlstra wrote:
On Wed, Nov 12, 2014 at 02:53:10PM +0100, Daniel Lezcano wrote:
The governors are just ignoring it, except for a small timer optimization in
menu.c (and I am still not convinced it is worth to have it). I don't see
the point to add a state we don't
On Wed, Nov 12, 2014 at 02:53:10PM +0100, Daniel Lezcano wrote:
> >>The governors are just ignoring it, except for a small timer optimization in
> >>menu.c (and I am still not convinced it is worth to have it). I don't see
> >>the point to add a state we don't want to use.
> >
> >The ignoring it
On 11/11/2014 11:20 AM, Peter Zijlstra wrote:
On Mon, Nov 10, 2014 at 11:21:19PM +0100, Daniel Lezcano wrote:
On 11/10/2014 08:48 PM, Peter Zijlstra wrote:
On Mon, Nov 10, 2014 at 06:19:02PM +0100, Daniel Lezcano wrote:
I really don't get why the governors should know about this though, its
On 11/11/2014 11:20 AM, Peter Zijlstra wrote:
On Mon, Nov 10, 2014 at 11:21:19PM +0100, Daniel Lezcano wrote:
On 11/10/2014 08:48 PM, Peter Zijlstra wrote:
On Mon, Nov 10, 2014 at 06:19:02PM +0100, Daniel Lezcano wrote:
I really don't get why the governors should know about this though, its
On Wed, Nov 12, 2014 at 02:53:10PM +0100, Daniel Lezcano wrote:
The governors are just ignoring it, except for a small timer optimization in
menu.c (and I am still not convinced it is worth to have it). I don't see
the point to add a state we don't want to use.
The ignoring it is _wrong_.
On 11/12/2014 04:02 PM, Peter Zijlstra wrote:
On Wed, Nov 12, 2014 at 02:53:10PM +0100, Daniel Lezcano wrote:
The governors are just ignoring it, except for a small timer optimization in
menu.c (and I am still not convinced it is worth to have it). I don't see
the point to add a state we don't
On Mon, Nov 10, 2014 at 11:21:19PM +0100, Daniel Lezcano wrote:
> On 11/10/2014 08:48 PM, Peter Zijlstra wrote:
> >On Mon, Nov 10, 2014 at 06:19:02PM +0100, Daniel Lezcano wrote:
> >>>I really don't get why the governors should know about this though, its
> >>>just another state, they should
On Mon, Nov 10, 2014 at 11:21:19PM +0100, Daniel Lezcano wrote:
On 11/10/2014 08:48 PM, Peter Zijlstra wrote:
On Mon, Nov 10, 2014 at 06:19:02PM +0100, Daniel Lezcano wrote:
I really don't get why the governors should know about this though, its
just another state, they should iterate all
On 11/10/2014 08:48 PM, Peter Zijlstra wrote:
On Mon, Nov 10, 2014 at 06:19:02PM +0100, Daniel Lezcano wrote:
I really don't get why the governors should know about this though, its
just another state, they should iterate all states and pick the best,
given the power usage this state should
On Mon, Nov 10, 2014 at 06:19:02PM +0100, Daniel Lezcano wrote:
> >I really don't get why the governors should know about this though, its
> >just another state, they should iterate all states and pick the best,
> >given the power usage this state should really never be eligible unless
> >we're
On 11/10/2014 05:15 PM, Peter Zijlstra wrote:
On Mon, Nov 10, 2014 at 04:58:29PM +0100, Daniel Lezcano wrote:
I don't get it, I've clearly not stared at it long enough, but why is
that STATE_START crap needed anywhere?
Excellent question :)
On x86, the config option ARCH_HAS_CPU_RELAX is set
On Mon, Nov 10, 2014 at 04:58:29PM +0100, Daniel Lezcano wrote:
> >I don't get it, I've clearly not stared at it long enough, but why is
> >that STATE_START crap needed anywhere?
>
> Excellent question :)
>
> On x86, the config option ARCH_HAS_CPU_RELAX is set (x86 is the only one).
> That leads
On 11/10/2014 04:28 PM, Peter Zijlstra wrote:
On Mon, Nov 10, 2014 at 04:12:47PM +0100, Daniel Lezcano wrote:
All this is to remove the poll idle state from the x86 cpuidle driver in
order to remove the CPUIDLE_DRIVER_STATE_START (this one forces to write
always ugly code in the cpuidle
On Mon, Nov 10, 2014 at 04:12:47PM +0100, Daniel Lezcano wrote:
> All this is to remove the poll idle state from the x86 cpuidle driver in
> order to remove the CPUIDLE_DRIVER_STATE_START (this one forces to write
> always ugly code in the cpuidle framework).
>
> This poll state introduces the
On 11/10/2014 01:41 PM, Peter Zijlstra wrote:
On Fri, Nov 07, 2014 at 03:31:23PM +0100, Daniel Lezcano wrote:
@@ -216,19 +219,26 @@ static void cpu_idle_loop(void)
local_irq_disable();
arch_cpu_idle_enter();
+ latency_req =
On Fri, Nov 07, 2014 at 03:31:23PM +0100, Daniel Lezcano wrote:
> @@ -216,19 +219,26 @@ static void cpu_idle_loop(void)
> local_irq_disable();
> arch_cpu_idle_enter();
>
> + latency_req = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
> +
On Fri, Nov 07, 2014 at 03:31:23PM +0100, Daniel Lezcano wrote:
@@ -216,19 +219,26 @@ static void cpu_idle_loop(void)
local_irq_disable();
arch_cpu_idle_enter();
+ latency_req = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
+
On 11/10/2014 01:41 PM, Peter Zijlstra wrote:
On Fri, Nov 07, 2014 at 03:31:23PM +0100, Daniel Lezcano wrote:
@@ -216,19 +219,26 @@ static void cpu_idle_loop(void)
local_irq_disable();
arch_cpu_idle_enter();
+ latency_req =
On Mon, Nov 10, 2014 at 04:12:47PM +0100, Daniel Lezcano wrote:
All this is to remove the poll idle state from the x86 cpuidle driver in
order to remove the CPUIDLE_DRIVER_STATE_START (this one forces to write
always ugly code in the cpuidle framework).
This poll state introduces the
On 11/10/2014 04:28 PM, Peter Zijlstra wrote:
On Mon, Nov 10, 2014 at 04:12:47PM +0100, Daniel Lezcano wrote:
All this is to remove the poll idle state from the x86 cpuidle driver in
order to remove the CPUIDLE_DRIVER_STATE_START (this one forces to write
always ugly code in the cpuidle
On Mon, Nov 10, 2014 at 04:58:29PM +0100, Daniel Lezcano wrote:
I don't get it, I've clearly not stared at it long enough, but why is
that STATE_START crap needed anywhere?
Excellent question :)
On x86, the config option ARCH_HAS_CPU_RELAX is set (x86 is the only one).
That leads to the
On 11/10/2014 05:15 PM, Peter Zijlstra wrote:
On Mon, Nov 10, 2014 at 04:58:29PM +0100, Daniel Lezcano wrote:
I don't get it, I've clearly not stared at it long enough, but why is
that STATE_START crap needed anywhere?
Excellent question :)
On x86, the config option ARCH_HAS_CPU_RELAX is set
On Mon, Nov 10, 2014 at 06:19:02PM +0100, Daniel Lezcano wrote:
I really don't get why the governors should know about this though, its
just another state, they should iterate all states and pick the best,
given the power usage this state should really never be eligible unless
we're QoS forced
On 11/10/2014 08:48 PM, Peter Zijlstra wrote:
On Mon, Nov 10, 2014 at 06:19:02PM +0100, Daniel Lezcano wrote:
I really don't get why the governors should know about this though, its
just another state, they should iterate all states and pick the best,
given the power usage this state should
On 11/07/2014 08:01 PM, Daniel Lezcano wrote:
> When the pmqos latency requirement is set to zero that means "poll in all the
> cases".
>
> That is correctly implemented on x86 but not on the other archs.
>
> As how is written the code, if the latency request is zero, the governor will
> return
On 11/07/2014 08:01 PM, Daniel Lezcano wrote:
When the pmqos latency requirement is set to zero that means poll in all the
cases.
That is correctly implemented on x86 but not on the other archs.
As how is written the code, if the latency request is zero, the governor will
return zero, so
When the pmqos latency requirement is set to zero that means "poll in all the
cases".
That is correctly implemented on x86 but not on the other archs.
As how is written the code, if the latency request is zero, the governor will
return zero, so corresponding, for x86, to the poll function, but
When the pmqos latency requirement is set to zero that means poll in all the
cases.
That is correctly implemented on x86 but not on the other archs.
As how is written the code, if the latency request is zero, the governor will
return zero, so corresponding, for x86, to the poll function, but for
28 matches
Mail list logo
