Re: [RFC PATCH] sched: wake-affine throttle

[Michael Wang <wangyun@linux.vnet.ibm.com>]

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)) {
>> +                       /*
>> +                        * wake_affine() stuff try to pull wakee to
>> the cpu
>> +                        * around waker, this will benefit us if the
>> data
>> +                        * cached on waker cpu is hot for wakee, or
>> the extreme
>> +                        * ping-pong case.
>> +                        *
>> +                        * However, do such blindly work too
>> frequently will
>> +                        * cause regression to some workload, thus,
>> each time
>> +                        * when wake_affine() succeed, throttle it for
>> a while.
>> +                        */
>> +                       wake_affine_throttle(p);
>>                         prev_cpu = cpu;
>> +               }
> 
> How about only throttling when wake_affine() starts returning false? At
> that point its lost its benefit.

Honestly, I used to think this won't work, but the testing results show
it even better than throttle on succeed...your suggestion is correct, it
will be applied to the next version.

But please allow me to express my concern here:

In summary, I don't think 'return false' is the only point wake-affine
lost it's benefit.

When wake-affine return true, the only thing guaranteed is the balance,
but what about the factors like:

1. wakee has no hot data cached on curr_cpu
2. hot data cached on curr_cpu for wakee is less than those on prev_cpu
3. wakee has no relationship with waker at all
...

Those factors was unconsidered when wake_affine() return true, but they
could be a reason for regression too, isn't it?

Anyway, according to the test results, the benefit of wake-affine
reserved by 'throttle on failed' is impressive, those factors failed to
defend them self...

> 
> Also, why not place this inside wake_affine() like you did the throttled
> test.

That's right, will correct it :)

Regards,
Michael Wang

> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>