linux-kernel - Re: [PATCH 04/14] sched: pack the idle load balance

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKfTPtB0B8gM7C75D6EwWxQV_PRYpo+q48ywY26k8KVHx+oiqA@mail.gmail.com>
Date:	Fri, 26 Apr 2013 15:47:33 +0200
From:	Vincent Guittot <vincent.guittot@...aro.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	LAK <linux-arm-kernel@...ts.infradead.org>,
	"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
	Ingo Molnar <mingo@...nel.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Paul Turner <pjt@...gle.com>,
	Santosh <santosh.shilimkar@...com>,
	Morten Rasmussen <Morten.Rasmussen@....com>,
	Chander Kashyap <chander.kashyap@...aro.org>,
	"cmetcalf@...era.com" <cmetcalf@...era.com>,
	"tony.luck@...el.com" <tony.luck@...el.com>,
	Alex Shi <alex.shi@...el.com>,
	Preeti U Murthy <preeti@...ux.vnet.ibm.com>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Len Brown <len.brown@...el.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Amit Kucheria <amit.kucheria@...aro.org>,
	Jonathan Corbet <corbet@....net>,
	Lukasz Majewski <l.majewski@...sung.com>
Subject: Re: [PATCH 04/14] sched: pack the idle load balance

On 26 April 2013 14:49, Peter Zijlstra <peterz@...radead.org> wrote:
> On Thu, Apr 25, 2013 at 07:23:20PM +0200, Vincent Guittot wrote:
>> Look for an idle CPU close to the pack buddy CPU whenever possible.
>> The goal is to prevent the wake up of a CPU which doesn't share the power
>> domain of the pack buddy CPU.
>>
>> Signed-off-by: Vincent Guittot <vincent.guittot@...aro.org>
>> Reviewed-by: Morten Rasmussen <morten.rasmussen@....com>
>> ---
>>  kernel/sched/fair.c |   19 +++++++++++++++++++
>>  1 file changed, 19 insertions(+)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 6adc57c..a985c98 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -5469,7 +5469,26 @@ static struct {
>>
>>  static inline int find_new_ilb(int call_cpu)
>>  {
>> +     struct sched_domain *sd;
>>       int ilb = cpumask_first(nohz.idle_cpus_mask);
>> +     int buddy = per_cpu(sd_pack_buddy, call_cpu);
>> +
>> +     /*
>> +      * If we have a pack buddy CPU, we try to run load balance on a CPU
>> +      * that is close to the buddy.
>> +      */
>> +     if (buddy != -1) {
>> +             for_each_domain(buddy, sd) {
>> +                     if (sd->flags & SD_SHARE_CPUPOWER)
>> +                             continue;
>> +
>> +                     ilb = cpumask_first_and(sched_domain_span(sd),
>> +                                     nohz.idle_cpus_mask);
>> +
>> +                     if (ilb < nr_cpu_ids)
>> +                             break;
>> +             }
>> +     }
>>
>>       if (ilb < nr_cpu_ids && idle_cpu(ilb))
>>               return ilb;
>
> Ha! and here you hope people won't put multiple big-little clusters in a single
> machine? :-)

yes, we will probably face this situation sooner or later but the
other little clusters will probably be not less close than the local
big cluster from a power domain point of view.
That's why i look for the small sched_domain level to the largest one

>
>
>
--
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/