linux-kernel - RE: [PATCH v8 03/10] sched: move cfs task on a CPU with higher capacity

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 for Android: free password hash cracker in your pocket

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

Message-ID: <011901cff833$b49afb30$1dd0f190$@alibaba-inc.com>
Date:	Tue, 04 Nov 2014 21:31:57 +0800
From:	"Hillf Danton" <hillf.zj@...baba-inc.com>
To:	"'Vincent Guittot'" <vincent.guittot@...aro.org>
Cc:	"'Wanpeng Li'" <kernellwp@...il.com>,
	"'Peter Zijlstra'" <peterz@...radead.org>,
	"'Ingo Molnar'" <mingo@...nel.org>,
	"'linux-kernel'" <linux-kernel@...r.kernel.org>,
	"'Preeti U Murthy'" <preeti@...ux.vnet.ibm.com>,
	"'Morten Rasmussen'" <Morten.Rasmussen@....com>,
	"'Kamalesh Babulal'" <kamalesh@...ux.vnet.ibm.com>
Subject: RE: [PATCH v8 03/10] sched: move cfs task on a CPU with higher capacity

> >> > I wonder if you can please shed light on the case that
> >> > the dst_cpu is newly idle.
> >>
> >> The main problem if we do the test only for newly idle case, is that
> >> we are not sure to move the task because we must rely on the
> >> wakeup/sleep sequence of other tasks on an idle CPU in order to trig
> >> the migration (periodic background task as an example). So we might
> >> never move the task whereas idle CPUs are available
> >>
> > So no task is migrated in the newly idle case, if I understand the
> > above correctly.
> 
> A task can be moved in both idle and newly idle. If we rely only on
> newly idle and we  have only idle CPUs, we can never move task. In the
> same way, if we rely only on idle case and a CPU never stays idle long
> enough to trig the idle load balance, we will never move the task. I
> agree that for the latter, we might wonder if it's worth moving the
> task. This is your concern ?
> 
I concern if the only-one cfs task is migrated to a newly-idle CPU in
your code:
+	/*
+	 * The dst_cpu is idle and the src_cpu CPU has only 1 CFS task.
+	 * It's worth migrating the task if the src_cpu's capacity is reduced
+	 * because of other sched_class or IRQs whereas capacity stays
+	 * available on dst_cpu.
+	 */
+	if ((env->idle != CPU_NOT_IDLE) &&
+			(env->src_rq->cfs.h_nr_running == 1)) {
+	
due to the comment:
                /*
                 * Increment the failure counter only on periodic balance.
                 * We do not want newidle balance, which can be very
                 * frequent, pollute the failure counter causing
                 * excessive cache_hot migrations and active balances.
                 */
                if (idle != CPU_NEWLY_IDLE)
                        sd->nr_balance_failed++;

Hillf

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