Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-08-02 Thread Jeremy Eder
On 130729 12:59:47, Jeremy Eder wrote: On 130729 23:57:31, Youquan Song wrote: Hi Jeremy, I try reproduce your result and then fix the issue, but I do not reproduce it yet. I run at netperf-2.6.0 at one machine as server: netserver, other machine: netperf -t TCP_RR -H

Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-07-29 Thread Arjan van de Ven
Beside that, on ARM the cpus could be coupled and the timer to detect the prediction will wake up the entire cluster, making the power saving less efficient and impacting the statistics of the other cpu. an ARM specific governor would be quite appropriate in that case. -- To unsubscribe from

Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-07-29 Thread Arjan van de Ven
The menu governor tries to deduce the next wakeup but based on events per cpu. That means if a task with a specific behavior is migrated across cpus, the statistics will be wrong. btw this is largely a misunderstanding; tasks are not the issue; tasks use timers and those are perfectly

Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-07-29 Thread Lorenzo Pieralisi
On Mon, Jul 29, 2013 at 02:12:58PM +0100, Arjan van de Ven wrote: The menu governor tries to deduce the next wakeup but based on events per cpu. That means if a task with a specific behavior is migrated across cpus, the statistics will be wrong. btw this is largely a misunderstanding;

Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-07-29 Thread Arjan van de Ven
On 7/29/2013 7:14 AM, Lorenzo Pieralisi wrote: btw this is largely a misunderstanding; tasks are not the issue; tasks use timers and those are perfectly predictable. It's interrupts that are not and the heuristics are for that. Now, if your hardware does the really-bad-for-power wake-all on

Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-07-29 Thread Lorenzo Pieralisi
On Mon, Jul 29, 2013 at 03:29:20PM +0100, Arjan van de Ven wrote: On 7/29/2013 7:14 AM, Lorenzo Pieralisi wrote: btw this is largely a misunderstanding; tasks are not the issue; tasks use timers and those are perfectly predictable. It's interrupts that are not and the heuristics are

Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-07-29 Thread Arjan van de Ven
On 7/29/2013 9:01 AM, Lorenzo Pieralisi wrote: Coupled C states on this level are a PAIN in many ways, and tend to totally suck for power due to this and the general too much is active reasons. I think the trend is moving towards core gating, which resembles a lot to what x86 world does

Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-07-29 Thread Youquan Song
Hi Jeremy, I try reproduce your result and then fix the issue, but I do not reproduce it yet. I run at netperf-2.6.0 at one machine as server: netserver, other machine: netperf -t TCP_RR -H $SERVER_IP -l 60. The target machine is used in both client and server. I do not reproduce the

Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-07-29 Thread Jeremy Eder
On 130729 23:57:31, Youquan Song wrote: Hi Jeremy, I try reproduce your result and then fix the issue, but I do not reproduce it yet. I run at netperf-2.6.0 at one machine as server: netserver, other machine: netperf -t TCP_RR -H $SERVER_IP -l 60. The target machine is used in both

Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-07-27 Thread Len Brown
OK, I'll queue up the reverts as fixes for 3.11-rc4. So, the reverts are on the fixes-next branch of the linux-pm.git tree that you can access at http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/log/?h=fixes-next However, they are not simple reverts as we've had some

Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-07-27 Thread Daniel Lezcano
On 07/26/2013 07:33 PM, Jeremy Eder wrote: Hello, We believe we've identified a particular commit to the cpuidle code that seems to be impacting performance of variety of workloads. The simplest way to reproduce is using netperf TCP_RR test, so we're using that, on a pair of Sandy Bridge

Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-07-27 Thread Daniel Lezcano
On 07/26/2013 08:29 PM, Rik van Riel wrote: On 07/26/2013 02:27 PM, Arjan van de Ven wrote: On 7/26/2013 11:13 AM, Rik van Riel wrote: Could you try running the tests with just the repeat mode stuff from commit 69a37bea excluded, but leaving the common infrastructure and commit e11538?

Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-07-27 Thread Rafael J. Wysocki
On Saturday, July 27, 2013 02:22:53 AM Len Brown wrote: OK, I'll queue up the reverts as fixes for 3.11-rc4. So, the reverts are on the fixes-next branch of the linux-pm.git tree that you can access at http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/log/?h=fixes-next

RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-07-26 Thread Jeremy Eder
Hello, We believe we've identified a particular commit to the cpuidle code that seems to be impacting performance of variety of workloads. The simplest way to reproduce is using netperf TCP_RR test, so we're using that, on a pair of Sandy Bridge based servers. We also have data from a large

Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-07-26 Thread Rik van Riel
On 07/26/2013 01:33 PM, Jeremy Eder wrote: Hello, We believe we've identified a particular commit to the cpuidle code that seems to be impacting performance of variety of workloads. The simplest way to reproduce is using netperf TCP_RR test, so we're using that, on a pair of Sandy Bridge based

Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-07-26 Thread Arjan van de Ven
On 7/26/2013 11:13 AM, Rik van Riel wrote: Could you try running the tests with just the repeat mode stuff from commit 69a37bea excluded, but leaving the common infrastructure and commit e11538? personally I think we should go the other way around. revert the set entirely first, and now,

Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-07-26 Thread Rik van Riel
On 07/26/2013 02:27 PM, Arjan van de Ven wrote: On 7/26/2013 11:13 AM, Rik van Riel wrote: Could you try running the tests with just the repeat mode stuff from commit 69a37bea excluded, but leaving the common infrastructure and commit e11538? personally I think we should go the other way

Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-07-26 Thread Rafael J. Wysocki
On Friday, July 26, 2013 02:29:40 PM Rik van Riel wrote: On 07/26/2013 02:27 PM, Arjan van de Ven wrote: On 7/26/2013 11:13 AM, Rik van Riel wrote: Could you try running the tests with just the repeat mode stuff from commit 69a37bea excluded, but leaving the common infrastructure and

Re: RFC: revert request for cpuidle patches e11538d1 and 69a37bea

2013-07-26 Thread Rafael J. Wysocki
On Friday, July 26, 2013 11:48:36 PM Rafael J. Wysocki wrote: On Friday, July 26, 2013 02:29:40 PM Rik van Riel wrote: On 07/26/2013 02:27 PM, Arjan van de Ven wrote: On 7/26/2013 11:13 AM, Rik van Riel wrote: Could you try running the tests with just the repeat mode stuff from