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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 09 Apr 2013 13:01:11 +0800
From:	Michael Wang <wangyun@...ux.vnet.ibm.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>
CC:	Mike Galbraith <efault@....de>, Namhyung Kim <namhyung@...nel.org>,
	Alex Shi <alex.shi@...el.com>, Paul Turner <pjt@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Nikunj A. Dadhania" <nikunj@...ux.vnet.ibm.com>,
	Ram Pai <linuxram@...ibm.com>
Subject: Re: [RFC PATCH] sched: wake-affine throttle

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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

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