From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932187AbbCaRaU (ORCPT ); Tue, 31 Mar 2015 13:30:20 -0400 Received: from g4t3425.houston.hp.com ([15.201.208.53]:53815 "EHLO g4t3425.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753069AbbCaRaR (ORCPT ); Tue, 31 Mar 2015 13:30:17 -0400 Message-ID: <1427823008.2492.19.camel@j-VirtualBox> Subject: Re: [PATCH V2] sched: Improve load balancing in the presence of idle CPUs From: Jason Low To: Preeti U Murthy Cc: Morten Rasmussen , Peter Zijlstra , "mingo@kernel.org" , "riel@redhat.com" , "daniel.lezcano@linaro.org" , "vincent.guittot@linaro.org" , "srikar@linux.vnet.ibm.com" , "pjt@google.com" , "benh@kernel.crashing.org" , "efault@gmx.de" , "linux-kernel@vger.kernel.org" , "iamjoonsoo.kim@lge.com" , "svaidy@linux.vnet.ibm.com" , "tim.c.chen@linux.intel.com" , jason.low2@hp.com Date: Tue, 31 Mar 2015 10:30:08 -0700 In-Reply-To: <551A61A9.6020009@linux.vnet.ibm.com> References: <20150326130014.21532.17158.stgit@preeti.in.ibm.com> <20150327143839.GO18994@e105550-lin.cambridge.arm.com> <55158966.4050300@linux.vnet.ibm.com> <20150327175651.GR18994@e105550-lin.cambridge.arm.com> <20150330110632.GT23123@twins.programming.kicks-ass.net> <20150330120302.GT18994@e105550-lin.cambridge.arm.com> <551A61A9.6020009@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2015-03-31 at 14:28 +0530, Preeti U Murthy wrote: > Morten, > I am a bit confused about the problem you are pointing to. > I am unable to see the issue. What is it that I am missing ? Hi Preeti, Here is one of the potential issues that have been described from my understanding. In situations where there are just a few tasks to pull (for example, there's 1 task to move). Before, if CPU 1 calls run_rebalance_domains(), we'll pull the tasks to this CPU 1 (which is already awake) and run the task on CPU 1. Now, we'll pull the task to some idle CPU 2 and wake up CPU 2 in order for the task to run. Meanwhile, CPU 1 may go idle, instead of running the task on CPU 1 which was already awake.