[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <545C4AA4.7010904@linux.vnet.ibm.com>
Date: Fri, 07 Nov 2014 09:59:24 +0530
From: Preeti U Murthy <preeti@...ux.vnet.ibm.com>
To: Daniel Lezcano <daniel.lezcano@...aro.org>
CC: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Nicolas Pitre <nicolas.pitre@...aro.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
patches@...aro.org
Subject: Re: [PATCH V2 1/5] sched: idle: cpuidle: Check the latency req before
idle
On 11/06/2014 07:12 PM, Daniel Lezcano wrote:
>
> Preeti,
>
> I am wondering if we aren't going to a false debate.
>
> If the latency_req is 0, we should just poll and not enter in any idle
> state even if one has zero exit latency. With a zero latency req, we
> want full reactivity on the system, not enter an idle state with all the
> computation in the menu governor, no ?
>
> I agree this patch changes the behavior on PowerPC, but only if the
> latency_req is set to zero. I don't think we are worried about power
> saving when setting this value.
>
> Couldn't the patch accepted as it is for the sake of consistency on all
> the platform and then we optimize cleanly for the special latency zero
> case ?
Alright Daniel, you can go ahead. I was thinking this patch through and
now realize that, like you point out the logic will only get complicated
with all the additional hack.
But would it be possible to add the weak arch_cpu_idle_loop() call for
the cases where latency requirement is 0 like you had suggested earlier
? This would ensure the polling logic does not break on PowerPC and we
don't bother the governor even. I will add the function in the core
PowerPC code. If arch does not define this function it will fall back to
cpu_idle_loop(). Fair enough?
Regards
Preeti U Murthy
--
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