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: <CAKfTPtCJzoYNEDu4WJWs0LraL59r8ZDuavBv9rypRKJiX4ZL7g@mail.gmail.com>
Date:	Fri, 26 Apr 2013 16:52:50 +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 08/14] sched: trig ILB on an idle buddy

On 26 April 2013 15:15, Peter Zijlstra <peterz@...radead.org> wrote:
> On Thu, Apr 25, 2013 at 07:23:24PM +0200, Vincent Guittot wrote:
>> If the buddy CPU is not full and currently idle, we trigger an Idle Load
>> Balance to give it the opportunity to pull more tasks.
>>
>> Signed-off-by: Vincent Guittot <vincent.guittot@...aro.org>
>> ---
>>  kernel/sched/fair.c |   24 ++++++++++++++++++++++++
>>  1 file changed, 24 insertions(+)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 874f330..954adfd 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -5776,6 +5776,26 @@ end:
>>       clear_bit(NOHZ_BALANCE_KICK, nohz_flags(this_cpu));
>>  }
>>
>> +static int check_nohz_buddy(int cpu)
>> +{
>> +     int buddy = per_cpu(sd_pack_buddy, cpu);
>> +
>> +     if (sysctl_sched_packing_mode != SCHED_PACKING_FULL)
>> +             return false;
>> +
>> +     /* No pack buddy for this CPU */
>> +     if (buddy == -1)
>> +             return false;
>> +
>> +     if (is_buddy_full(buddy))
>> +             return false;
>> +
>> +     if (cpumask_test_cpu(buddy, nohz.idle_cpus_mask))
>> +             return true;
>> +
>> +     return false;
>
> return cpumask_test_cpu(..); ?

right

>
>> +}
>> +
>>  /*
>>   * Current heuristic for kicking the idle load balancer in the presence
>>   * of an idle cpu is the system.
>> @@ -5813,6 +5833,10 @@ static inline int nohz_kick_needed(struct rq *rq, int cpu)
>>       if (rq->nr_running >= 2)
>>               goto need_kick;
>>
>> +     /* the buddy is idle and not busy so we can pack */
>> +     if (check_nohz_buddy(cpu))
>> +             goto need_kick;
>> +
>>       rcu_read_lock();
>>       for_each_domain(cpu, sd) {
>>               struct sched_group *sg = sd->groups;
>
> Bah.. this code is so confusing.. nohz_balance_kick(cpu) won't actually kick
> @cpu.
>
> Again.. suppose we're a big cpu (2) and our little buddy cpu (0) is busy, we
> miss an opportunity to kick the other little cpu into gear (1) and maybe take
> the big core out.

You're right that we can miss an opportunity but it means that cpus
allocated to packing effort are full and a new buddy cpu is going to
be allocated and will pull the task a bit later.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ