On 04/10/2013 11:30 AM, Michael Wang wrote:
> Log since RFC:
> 1. Throttle only when wake-affine failed. (thanks to PeterZ)
> 2. Do throttle inside wake_affine(). (thanks to PeterZ)
> 3. Other small fix.
>
> Recently testing show that wake-affine stuff cause regression on
On 05/03/2013 11:46 AM, Michael Wang wrote:
> On 04/10/2013 11:30 AM, Michael Wang wrote:
>
> Now long time has been passed since the first version, I'd like to
> do some summary about current states:
>
> On a 12 cpu box with tip 3.9.0-rc7, test show that:
>
> 1. remove wake-affine stuff cause
On 05/03/2013 11:46 AM, Michael Wang wrote:
On 04/10/2013 11:30 AM, Michael Wang wrote:
Now long time has been passed since the first version, I'd like to
do some summary about current states:
On a 12 cpu box with tip 3.9.0-rc7, test show that:
1. remove wake-affine stuff cause
On 04/10/2013 11:30 AM, Michael Wang wrote:
Log since RFC:
1. Throttle only when wake-affine failed. (thanks to PeterZ)
2. Do throttle inside wake_affine(). (thanks to PeterZ)
3. Other small fix.
Recently testing show that wake-affine stuff cause regression on pgbench, the
On 05/07/2013 10:46 AM, Michael Wang wrote:
> On 05/03/2013 11:46 AM, Michael Wang wrote:
>> On 04/10/2013 11:30 AM, Michael Wang wrote:
>>
>> Now long time has been passed since the first version, I'd like to
>> do some summary about current states:
>>
>> On a 12 cpu box with tip 3.9.0-rc7, test
On 05/07/2013 10:46 AM, Michael Wang wrote:
On 05/03/2013 11:46 AM, Michael Wang wrote:
On 04/10/2013 11:30 AM, Michael Wang wrote:
Now long time has been passed since the first version, I'd like to
do some summary about current states:
On a 12 cpu box with tip 3.9.0-rc7, test show that:
On 05/03/2013 11:46 AM, Michael Wang wrote:
> On 04/10/2013 11:30 AM, Michael Wang wrote:
>
> Now long time has been passed since the first version, I'd like to
> do some summary about current states:
>
> On a 12 cpu box with tip 3.9.0-rc7, test show that:
>
> 1. remove wake-affine stuff cause
On 05/03/2013 11:46 AM, Michael Wang wrote:
On 04/10/2013 11:30 AM, Michael Wang wrote:
Now long time has been passed since the first version, I'd like to
do some summary about current states:
On a 12 cpu box with tip 3.9.0-rc7, test show that:
1. remove wake-affine stuff cause
On 05/03/2013 02:14 PM, Mike Galbraith wrote:
> On Fri, 2013-05-03 at 13:57 +0800, Michael Wang wrote:
>> Hi, Mike
>>
>> Thanks for your reply.
>>
>> On 05/03/2013 01:01 PM, Mike Galbraith wrote:
>> [snip]
If this approach caused any concerns, please let me know ;-)
>>>
>>> I wonder if
On Fri, 2013-05-03 at 13:57 +0800, Michael Wang wrote:
> Hi, Mike
>
> Thanks for your reply.
>
> On 05/03/2013 01:01 PM, Mike Galbraith wrote:
> [snip]
> >>
> >> If this approach caused any concerns, please let me know ;-)
> >
> > I wonder if throttling on failure is the way to go. Note the
On Fri, 2013-05-03 at 13:57 +0800, Michael Wang wrote:
Hi, Mike
Thanks for your reply.
On 05/03/2013 01:01 PM, Mike Galbraith wrote:
[snip]
If this approach caused any concerns, please let me know ;-)
I wonder if throttling on failure is the way to go. Note the minimal
gain
On 05/03/2013 02:14 PM, Mike Galbraith wrote:
On Fri, 2013-05-03 at 13:57 +0800, Michael Wang wrote:
Hi, Mike
Thanks for your reply.
On 05/03/2013 01:01 PM, Mike Galbraith wrote:
[snip]
If this approach caused any concerns, please let me know ;-)
I wonder if throttling on failure is
Hi, Mike
Thanks for your reply.
On 05/03/2013 01:01 PM, Mike Galbraith wrote:
[snip]
>>
>> If this approach caused any concerns, please let me know ;-)
>
> I wonder if throttling on failure is the way to go. Note the minimal
> gain for pgbench with the default 1ms throttle interval. It's not
On Fri, 2013-05-03 at 11:46 +0800, Michael Wang wrote:
> On 04/10/2013 11:30 AM, Michael Wang wrote:
>
> Now long time has been passed since the first version, I'd like to
> do some summary about current states:
>
> On a 12 cpu box with tip 3.9.0-rc7, test show that:
>
> 1. remove wake-affine
On 04/10/2013 11:30 AM, Michael Wang wrote:
Now long time has been passed since the first version, I'd like to
do some summary about current states:
On a 12 cpu box with tip 3.9.0-rc7, test show that:
1. remove wake-affine stuff cause regression on hackbench (could be 15%).
2. reserve
On 05/02/2013 03:10 PM, Mike Galbraith wrote:
>>
>> I've done the test for several times, also compared with the throttle
>> approach, default 1ms interval still works very well, the regression on
>> hackbench start to exceed 2% when interval become 100ms on my box, but
>> please note the pgbench
On Thu, 2013-05-02 at 13:48 +0800, Michael Wang wrote:
> On 04/22/2013 06:23 PM, Peter Zijlstra wrote:
> >
> > OK,.. Ingo said that pipe-test was the original motivation for
> > wake_affine() and since that's currently broken to pieces due to
> > select_idle_sibling() is there still a benefit to
On Thu, 2013-05-02 at 13:48 +0800, Michael Wang wrote:
On 04/22/2013 06:23 PM, Peter Zijlstra wrote:
OK,.. Ingo said that pipe-test was the original motivation for
wake_affine() and since that's currently broken to pieces due to
select_idle_sibling() is there still a benefit to having
On 05/02/2013 03:10 PM, Mike Galbraith wrote:
I've done the test for several times, also compared with the throttle
approach, default 1ms interval still works very well, the regression on
hackbench start to exceed 2% when interval become 100ms on my box, but
please note the pgbench already
On 04/10/2013 11:30 AM, Michael Wang wrote:
Now long time has been passed since the first version, I'd like to
do some summary about current states:
On a 12 cpu box with tip 3.9.0-rc7, test show that:
1. remove wake-affine stuff cause regression on hackbench (could be 15%).
2. reserve
On Fri, 2013-05-03 at 11:46 +0800, Michael Wang wrote:
On 04/10/2013 11:30 AM, Michael Wang wrote:
Now long time has been passed since the first version, I'd like to
do some summary about current states:
On a 12 cpu box with tip 3.9.0-rc7, test show that:
1. remove wake-affine stuff
Hi, Mike
Thanks for your reply.
On 05/03/2013 01:01 PM, Mike Galbraith wrote:
[snip]
If this approach caused any concerns, please let me know ;-)
I wonder if throttling on failure is the way to go. Note the minimal
gain for pgbench with the default 1ms throttle interval. It's not very
On 04/22/2013 06:23 PM, Peter Zijlstra wrote:
>
> OK,.. Ingo said that pipe-test was the original motivation for
> wake_affine() and since that's currently broken to pieces due to
> select_idle_sibling() is there still a benefit to having it at all?
>
> Can anybody find any significant
On 04/22/2013 06:23 PM, Peter Zijlstra wrote:
OK,.. Ingo said that pipe-test was the original motivation for
wake_affine() and since that's currently broken to pieces due to
select_idle_sibling() is there still a benefit to having it at all?
Can anybody find any significant regression when
On 04/22/2013 06:23 PM, Peter Zijlstra wrote:
>
> OK,.. Ingo said that pipe-test was the original motivation for
> wake_affine() and since that's currently broken to pieces due to
> select_idle_sibling() is there still a benefit to having it at all?
>
> Can anybody find any significant
On 04/22/2013 06:23 PM, Peter Zijlstra wrote:
OK,.. Ingo said that pipe-test was the original motivation for
wake_affine() and since that's currently broken to pieces due to
select_idle_sibling() is there still a benefit to having it at all?
Can anybody find any significant regression when
On 04/22/2013 06:35 PM, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
>> OK,.. Ingo said that pipe-test was the original motivation for
>> wake_affine() and since that's currently broken to pieces due to
>> select_idle_sibling() is there still a benefit to having it at all?
>>
>> Can
On 04/22/2013 06:23 PM, Peter Zijlstra wrote:
>
> OK,.. Ingo said that pipe-test was the original motivation for
> wake_affine() and since that's currently broken to pieces due to
> select_idle_sibling() is there still a benefit to having it at all?
>
> Can anybody find any significant
On Mon, Apr 22, 2013 at 3:23 AM, Peter Zijlstra wrote:
>
> OK,.. Ingo said that pipe-test was the original motivation for
> wake_affine() and since that's currently broken to pieces due to
> select_idle_sibling() is there still a benefit to having it at all?
>
> Can anybody find any significant
* Peter Zijlstra wrote:
> OK,.. Ingo said that pipe-test was the original motivation for
> wake_affine() and since that's currently broken to pieces due to
> select_idle_sibling() is there still a benefit to having it at all?
>
> Can anybody find any significant regression when simply
OK,.. Ingo said that pipe-test was the original motivation for
wake_affine() and since that's currently broken to pieces due to
select_idle_sibling() is there still a benefit to having it at all?
Can anybody find any significant regression when simply killing
wake_affine()?
--
To unsubscribe
Hi, Mike
Thanks for your reply :)
On 04/22/2013 01:27 PM, Mike Galbraith wrote:
> On Mon, 2013-04-22 at 12:21 +0800, Michael Wang wrote:
>> On 04/10/2013 11:30 AM, Michael Wang wrote:
>>> Log since RFC:
>>> 1. Throttle only when wake-affine failed. (thanks to PeterZ)
>>> 2. Do throttle
Hi, Mike
Thanks for your reply :)
On 04/22/2013 01:27 PM, Mike Galbraith wrote:
On Mon, 2013-04-22 at 12:21 +0800, Michael Wang wrote:
On 04/10/2013 11:30 AM, Michael Wang wrote:
Log since RFC:
1. Throttle only when wake-affine failed. (thanks to PeterZ)
2. Do throttle inside
OK,.. Ingo said that pipe-test was the original motivation for
wake_affine() and since that's currently broken to pieces due to
select_idle_sibling() is there still a benefit to having it at all?
Can anybody find any significant regression when simply killing
wake_affine()?
--
To unsubscribe
* Peter Zijlstra pet...@infradead.org wrote:
OK,.. Ingo said that pipe-test was the original motivation for
wake_affine() and since that's currently broken to pieces due to
select_idle_sibling() is there still a benefit to having it at all?
Can anybody find any significant regression
On Mon, Apr 22, 2013 at 3:23 AM, Peter Zijlstra pet...@infradead.org wrote:
OK,.. Ingo said that pipe-test was the original motivation for
wake_affine() and since that's currently broken to pieces due to
select_idle_sibling() is there still a benefit to having it at all?
Can anybody find any
On 04/22/2013 06:23 PM, Peter Zijlstra wrote:
OK,.. Ingo said that pipe-test was the original motivation for
wake_affine() and since that's currently broken to pieces due to
select_idle_sibling() is there still a benefit to having it at all?
Can anybody find any significant regression when
On 04/22/2013 06:35 PM, Ingo Molnar wrote:
* Peter Zijlstra pet...@infradead.org wrote:
OK,.. Ingo said that pipe-test was the original motivation for
wake_affine() and since that's currently broken to pieces due to
select_idle_sibling() is there still a benefit to having it at all?
On Mon, 2013-04-22 at 12:21 +0800, Michael Wang wrote:
> On 04/10/2013 11:30 AM, Michael Wang wrote:
> > Log since RFC:
> > 1. Throttle only when wake-affine failed. (thanks to PeterZ)
> > 2. Do throttle inside wake_affine(). (thanks to PeterZ)
> > 3. Other small fix.
> >
> >
On 04/10/2013 11:30 AM, Michael Wang wrote:
> Log since RFC:
> 1. Throttle only when wake-affine failed. (thanks to PeterZ)
> 2. Do throttle inside wake_affine(). (thanks to PeterZ)
> 3. Other small fix.
>
> Recently testing show that wake-affine stuff cause regression on
On 04/10/2013 11:30 AM, Michael Wang wrote:
Log since RFC:
1. Throttle only when wake-affine failed. (thanks to PeterZ)
2. Do throttle inside wake_affine(). (thanks to PeterZ)
3. Other small fix.
Recently testing show that wake-affine stuff cause regression on pgbench, the
On Mon, 2013-04-22 at 12:21 +0800, Michael Wang wrote:
On 04/10/2013 11:30 AM, Michael Wang wrote:
Log since RFC:
1. Throttle only when wake-affine failed. (thanks to PeterZ)
2. Do throttle inside wake_affine(). (thanks to PeterZ)
3. Other small fix.
Recently testing
On 04/10/2013 04:51 PM, Peter Zijlstra wrote:
> On Wed, 2013-04-10 at 11:30 +0800, Michael Wang wrote:
>> | 15 GB | 32 | 35918 | | 37632 | +4.77% | 47923 | +33.42% |
>> 52241 | +45.45%
>
> So I don't get this... is wake_affine() once every milisecond _that_
> expensive?
>
> Seeing we
On 04/11/2013 04:44 PM, Mike Galbraith wrote:
> On Thu, 2013-04-11 at 16:26 +0800, Michael Wang wrote:
>
>> The 1:N is a good reason to explain why the chance that wakee's hot data
>> cached on curr_cpu is lower, and since it's just 'lower' not 'extinct',
>> after the throttle interval large
On Thu, 2013-04-11 at 10:44 +0200, Mike Galbraith wrote:
> On Thu, 2013-04-11 at 16:26 +0800, Michael Wang wrote:
>
> > The 1:N is a good reason to explain why the chance that wakee's hot data
> > cached on curr_cpu is lower, and since it's just 'lower' not 'extinct',
> > after the throttle
On Thu, 2013-04-11 at 16:26 +0800, Michael Wang wrote:
> The 1:N is a good reason to explain why the chance that wakee's hot data
> cached on curr_cpu is lower, and since it's just 'lower' not 'extinct',
> after the throttle interval large enough, it will be balanced, this
> could be proved,
Hi, Mike
On 04/11/2013 03:30 PM, Mike Galbraith wrote:
[snip]
>>
>> Please let me know if I failed to express my thought clearly.
>>
>> I know it's hard to figure out why throttle could bring so many benefit,
>> since the wake-affine stuff is a black box with too many unmeasurable
>> factors, but
On Thu, 2013-04-11 at 14:01 +0800, Michael Wang wrote:
> On 04/10/2013 05:22 PM, Michael Wang wrote:
> > Hi, Peter
> >
> > Thanks for your reply :)
> >
> > On 04/10/2013 04:51 PM, Peter Zijlstra wrote:
> >> On Wed, 2013-04-10 at 11:30 +0800, Michael Wang wrote:
> >>> | 15 GB | 32 | 35918
On 04/10/2013 05:22 PM, Michael Wang wrote:
> Hi, Peter
>
> Thanks for your reply :)
>
> On 04/10/2013 04:51 PM, Peter Zijlstra wrote:
>> On Wed, 2013-04-10 at 11:30 +0800, Michael Wang wrote:
>>> | 15 GB | 32 | 35918 | | 37632 | +4.77% | 47923 | +33.42% |
>>> 52241 | +45.45%
>>
>> So I
On 04/10/2013 05:22 PM, Michael Wang wrote:
Hi, Peter
Thanks for your reply :)
On 04/10/2013 04:51 PM, Peter Zijlstra wrote:
On Wed, 2013-04-10 at 11:30 +0800, Michael Wang wrote:
| 15 GB | 32 | 35918 | | 37632 | +4.77% | 47923 | +33.42% |
52241 | +45.45%
So I don't get
On Thu, 2013-04-11 at 14:01 +0800, Michael Wang wrote:
On 04/10/2013 05:22 PM, Michael Wang wrote:
Hi, Peter
Thanks for your reply :)
On 04/10/2013 04:51 PM, Peter Zijlstra wrote:
On Wed, 2013-04-10 at 11:30 +0800, Michael Wang wrote:
| 15 GB | 32 | 35918 | | 37632 |
Hi, Mike
On 04/11/2013 03:30 PM, Mike Galbraith wrote:
[snip]
Please let me know if I failed to express my thought clearly.
I know it's hard to figure out why throttle could bring so many benefit,
since the wake-affine stuff is a black box with too many unmeasurable
factors, but that's
On Thu, 2013-04-11 at 16:26 +0800, Michael Wang wrote:
The 1:N is a good reason to explain why the chance that wakee's hot data
cached on curr_cpu is lower, and since it's just 'lower' not 'extinct',
after the throttle interval large enough, it will be balanced, this
could be proved, since
On Thu, 2013-04-11 at 10:44 +0200, Mike Galbraith wrote:
On Thu, 2013-04-11 at 16:26 +0800, Michael Wang wrote:
The 1:N is a good reason to explain why the chance that wakee's hot data
cached on curr_cpu is lower, and since it's just 'lower' not 'extinct',
after the throttle interval
On 04/11/2013 04:44 PM, Mike Galbraith wrote:
On Thu, 2013-04-11 at 16:26 +0800, Michael Wang wrote:
The 1:N is a good reason to explain why the chance that wakee's hot data
cached on curr_cpu is lower, and since it's just 'lower' not 'extinct',
after the throttle interval large enough, it
On 04/10/2013 04:51 PM, Peter Zijlstra wrote:
On Wed, 2013-04-10 at 11:30 +0800, Michael Wang wrote:
| 15 GB | 32 | 35918 | | 37632 | +4.77% | 47923 | +33.42% |
52241 | +45.45%
So I don't get this... is wake_affine() once every milisecond _that_
expensive?
Seeing we get a 45%!!
Hi, Peter
Thanks for your reply :)
On 04/10/2013 04:51 PM, Peter Zijlstra wrote:
> On Wed, 2013-04-10 at 11:30 +0800, Michael Wang wrote:
>> | 15 GB | 32 | 35918 | | 37632 | +4.77% | 47923 | +33.42% |
>> 52241 | +45.45%
>
> So I don't get this... is wake_affine() once every milisecond
On Wed, 2013-04-10 at 11:30 +0800, Michael Wang wrote:
> | 15 GB | 32 | 35918 | | 37632 | +4.77% | 47923 | +33.42% |
> 52241 | +45.45%
So I don't get this... is wake_affine() once every milisecond _that_
expensive?
Seeing we get a 45%!! improvement out of once every 100ms that would
On Wed, 2013-04-10 at 11:30 +0800, Michael Wang wrote:
| 15 GB | 32 | 35918 | | 37632 | +4.77% | 47923 | +33.42% |
52241 | +45.45%
So I don't get this... is wake_affine() once every milisecond _that_
expensive?
Seeing we get a 45%!! improvement out of once every 100ms that would
mean
Hi, Peter
Thanks for your reply :)
On 04/10/2013 04:51 PM, Peter Zijlstra wrote:
On Wed, 2013-04-10 at 11:30 +0800, Michael Wang wrote:
| 15 GB | 32 | 35918 | | 37632 | +4.77% | 47923 | +33.42% |
52241 | +45.45%
So I don't get this... is wake_affine() once every milisecond _that_
On 04/10/2013 01:11 PM, Michael Wang wrote:
>> > BTW, could you try the kbulid, hackbench and aim for this?
> Sure, the patch has already been tested with aim7, also the hackbench,
> kbench, and ebizzy, no notable changes on my box with the default 1ms
> interval.
That's fine.
--
Thanks Alex
--
On 04/10/2013 12:16 PM, Alex Shi wrote:
> On 04/10/2013 11:30 AM, Michael Wang wrote:
>> Suggested-by: Peter Zijlstra
>> Signed-off-by: Michael Wang
>
> Reviewed-by: Alex Shi
Thanks for your review :)
>
> BTW, could you try the kbulid, hackbench and aim for this?
Sure, the patch has
On 04/10/2013 11:30 AM, Michael Wang wrote:
> Suggested-by: Peter Zijlstra
> Signed-off-by: Michael Wang
Reviewed-by: Alex Shi
BTW, could you try the kbulid, hackbench and aim for this?
--
Thanks Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Log since RFC:
1. Throttle only when wake-affine failed. (thanks to PeterZ)
2. Do throttle inside wake_affine(). (thanks to PeterZ)
3. Other small fix.
Recently testing show that wake-affine stuff cause regression on pgbench, the
hiding rat was finally catched out.
Log since RFC:
1. Throttle only when wake-affine failed. (thanks to PeterZ)
2. Do throttle inside wake_affine(). (thanks to PeterZ)
3. Other small fix.
Recently testing show that wake-affine stuff cause regression on pgbench, the
hiding rat was finally catched out.
On 04/10/2013 11:30 AM, Michael Wang wrote:
Suggested-by: Peter Zijlstra a.p.zijls...@chello.nl
Signed-off-by: Michael Wang wang...@linux.vnet.ibm.com
Reviewed-by: Alex Shi alex@intel.com
BTW, could you try the kbulid, hackbench and aim for this?
--
Thanks Alex
--
To unsubscribe from
On 04/10/2013 12:16 PM, Alex Shi wrote:
On 04/10/2013 11:30 AM, Michael Wang wrote:
Suggested-by: Peter Zijlstra a.p.zijls...@chello.nl
Signed-off-by: Michael Wang wang...@linux.vnet.ibm.com
Reviewed-by: Alex Shi alex@intel.com
Thanks for your review :)
BTW, could you try the
On 04/10/2013 01:11 PM, Michael Wang wrote:
BTW, could you try the kbulid, hackbench and aim for this?
Sure, the patch has already been tested with aim7, also the hackbench,
kbench, and ebizzy, no notable changes on my box with the default 1ms
interval.
That's fine.
--
Thanks Alex
--
To
On 04/08/2013 06:00 PM, Peter Zijlstra wrote:
> On Mon, 2013-03-25 at 13:24 +0800, Michael Wang wrote:
>> if (affine_sd) {
>> - if (cpu != prev_cpu && wake_affine(affine_sd, p,
>> sync))
>> + if (cpu != prev_cpu && wake_affine(affine_sd, p,
>> sync)) {
>> +
On Mon, 2013-03-25 at 13:24 +0800, Michael Wang wrote:
> if (affine_sd) {
> - if (cpu != prev_cpu && wake_affine(affine_sd, p,
> sync))
> + if (cpu != prev_cpu && wake_affine(affine_sd, p,
> sync)) {
> + /*
> +*
On Mon, 2013-03-25 at 13:24 +0800, Michael Wang wrote:
if (affine_sd) {
- if (cpu != prev_cpu wake_affine(affine_sd, p,
sync))
+ if (cpu != prev_cpu wake_affine(affine_sd, p,
sync)) {
+ /*
+* wake_affine()
On 04/08/2013 06:00 PM, Peter Zijlstra wrote:
On Mon, 2013-03-25 at 13:24 +0800, Michael Wang wrote:
if (affine_sd) {
- if (cpu != prev_cpu wake_affine(affine_sd, p,
sync))
+ if (cpu != prev_cpu wake_affine(affine_sd, p,
sync)) {
+
On 03/25/2013 01:24 PM, Michael Wang wrote:
> Recently testing show that wake-affine stuff cause regression on pgbench, the
> hiding rat was finally catched out.
>
> wake-affine stuff is always trying to pull wakee close to waker, by theory,
> this will benefit us if waker's cpu cached hot data
On 03/25/2013 01:24 PM, Michael Wang wrote:
Recently testing show that wake-affine stuff cause regression on pgbench, the
hiding rat was finally catched out.
wake-affine stuff is always trying to pull wakee close to waker, by theory,
this will benefit us if waker's cpu cached hot data for
On 03/25/2013 10:31 PM, Mike Galbraith wrote:
[snip]
>>
>> Do you mean 1ms interval is still too big? and you prefer to have a 0
>> option?
>
> Not really, I just think a fixed interval may not be good enough without
> some idle time consideration. Once a single load gets going less
> balancing
On Mon, 2013-03-25 at 18:21 +0800, Michael Wang wrote:
> Hi, Mike
>
> Thanks for your reply :)
>
> On 03/25/2013 05:22 PM, Mike Galbraith wrote:
> > On Mon, 2013-03-25 at 13:24 +0800, Michael Wang wrote:
> >> Recently testing show that wake-affine stuff cause regression on pgbench,
> >> the
>
Hi, Mike
Thanks for your reply :)
On 03/25/2013 05:22 PM, Mike Galbraith wrote:
> On Mon, 2013-03-25 at 13:24 +0800, Michael Wang wrote:
>> Recently testing show that wake-affine stuff cause regression on pgbench, the
>> hiding rat was finally catched out.
>>
>> wake-affine stuff is always
On Mon, 2013-03-25 at 13:24 +0800, Michael Wang wrote:
> Recently testing show that wake-affine stuff cause regression on pgbench, the
> hiding rat was finally catched out.
>
> wake-affine stuff is always trying to pull wakee close to waker, by theory,
> this will benefit us if waker's cpu
On Mon, 2013-03-25 at 13:24 +0800, Michael Wang wrote:
Recently testing show that wake-affine stuff cause regression on pgbench, the
hiding rat was finally catched out.
wake-affine stuff is always trying to pull wakee close to waker, by theory,
this will benefit us if waker's cpu cached hot
Hi, Mike
Thanks for your reply :)
On 03/25/2013 05:22 PM, Mike Galbraith wrote:
On Mon, 2013-03-25 at 13:24 +0800, Michael Wang wrote:
Recently testing show that wake-affine stuff cause regression on pgbench, the
hiding rat was finally catched out.
wake-affine stuff is always trying to
On Mon, 2013-03-25 at 18:21 +0800, Michael Wang wrote:
Hi, Mike
Thanks for your reply :)
On 03/25/2013 05:22 PM, Mike Galbraith wrote:
On Mon, 2013-03-25 at 13:24 +0800, Michael Wang wrote:
Recently testing show that wake-affine stuff cause regression on pgbench,
the
hiding rat
On 03/25/2013 10:31 PM, Mike Galbraith wrote:
[snip]
Do you mean 1ms interval is still too big? and you prefer to have a 0
option?
Not really, I just think a fixed interval may not be good enough without
some idle time consideration. Once a single load gets going less
balancing is more,
Recently testing show that wake-affine stuff cause regression on pgbench, the
hiding rat was finally catched out.
wake-affine stuff is always trying to pull wakee close to waker, by theory,
this will benefit us if waker's cpu cached hot data for wakee, or the extreme
ping-pong case.
However, the
Recently testing show that wake-affine stuff cause regression on pgbench, the
hiding rat was finally catched out.
wake-affine stuff is always trying to pull wakee close to waker, by theory,
this will benefit us if waker's cpu cached hot data for wakee, or the extreme
ping-pong case.
However, the
84 matches
Mail list logo
