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
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/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/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 t
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 mi
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 v
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 wake-affi
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 a
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 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
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
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 anybod
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
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 re
* 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 killing
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 fr
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 i
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
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
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
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 enoug
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 inter
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
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
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
mean
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 already
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 a
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.
wake-af
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)) {
> + /*
> +* wake_
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 fo
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 i
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 tryin
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
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
42 matches
Mail list logo
