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
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
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
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
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
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
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
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
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
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
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
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
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;
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
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
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
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
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
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
> >
> >
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
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
>> 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
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
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
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?
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
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
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
> >>
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
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,
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
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
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
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
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,
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
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
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
38 matches
Mail list logo
