From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 01BDFA59 for ; Fri, 26 Jun 2026 00:02:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782432140; cv=none; b=TqfJUNUtZ1fLWdSGjQLNKmDI1wijqokF/GXfIzWok7a9Ma85JkTVs/3IFCpcJb7j06QWL8qwqX9cIzLMmDlObW+OD6gychGUb0OU4Afsgh+lvRusqiJDRjca+BAjdq8uEx1oUVLCpHJtttO3DsaewpuSYQjwFKRvsgCYIqAHtaI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782432140; c=relaxed/simple; bh=wQhuyBdruY2SyrwRRAfAMiDVzjv7SHRmYogywsQnQq8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=K7AZhFERxXRxnuqr9kOMCibmFyacL1Hfysi5sImyQtASmLNb/qUy9RTAUVoP4JQI/fplrEvyhTWEthSvEp4D8S6za29U7JihWvT/oXAWLx5kSWKxrfdiFOhKxCJgDhg5jdFSOhkJ6ETcARR+OlerTHMDxy4lL5SbhMWxxm1Nn6c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=n/XTfoP2; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="n/XTfoP2" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1782432138; x=1813968138; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=wQhuyBdruY2SyrwRRAfAMiDVzjv7SHRmYogywsQnQq8=; b=n/XTfoP2H3Qd7w8Km1dm/b6A8HX+LV45r6q9G/SIZU+ALP8f3pp5FmL/ JpHesc/RtZj5JfxJ6zj8sBCBOEJhAKLy+u5/CSSh+WbdHu0e6ANY+NRjq 0dq76RLoVZkLXOPVchVHLNAYcZ9eJ/pnKOoMYo3N7MBlbmIpU2H3+A5Ez lOjD3aI12TfCvuun6HwOmkjpW7d1X2briGFLQUjrl2ahZ4AI53hGk2Z4v eUpOdO+9WBnTwiX5yBg1xNuKTBiaZJDg6Rd0SZlCwxCYabp0HOusDYT7e 6hsQdxDsQIm57fBRRY02klOqVSv0bWB69mqkW37m2pVuYFzN/GHiTg6w/ Q==; X-CSE-ConnectionGUID: Lj+mEAXfQQyszNp+lxPitA== X-CSE-MsgGUID: TUZit6kvTNGP+Gv/sul0yQ== X-IronPort-AV: E=McAfee;i="6800,10657,11828"; a="94370752" X-IronPort-AV: E=Sophos;i="6.24,225,1774335600"; d="scan'208";a="94370752" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jun 2026 17:02:17 -0700 X-CSE-ConnectionGUID: h7JcMH/HQQORn1BiG1Ze0Q== X-CSE-MsgGUID: gIBR9LcgQHWHg24r2YtIng== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,225,1774335600"; d="scan'208";a="254783709" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by orviesa003.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jun 2026 17:02:16 -0700 Date: Thu, 25 Jun 2026 17:11:38 -0700 From: Ricardo Neri To: Christian Loehle , g@ranerica-svr.sc.intel.com Cc: Vincent Guittot , Ingo Molnar , Peter Zijlstra , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Tim C Chen , Chen Yu , K Prateek Nayak , Barry Song , "Rafael J. Wysocki" , Andrea Righi , Len Brown , ricardo.neri@intel.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 5/6] sched/fair: Allow load balancing between CPUs of identical capacity Message-ID: <20260626001138.GA19085@ranerica-svr.sc.intel.com> References: <20260622-rneri-fix-cas-clusters-v5-0-19968f2d1497@linux.intel.com> <20260622-rneri-fix-cas-clusters-v5-5-19968f2d1497@linux.intel.com> <20260624052514.GA16859@ranerica-svr.sc.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260624052514.GA16859@ranerica-svr.sc.intel.com> User-Agent: Mutt/1.9.4 (2018-02-28) On Tue, Jun 23, 2026 at 10:25:14PM -0700, Ricardo Neri wrote: > On Tue, Jun 23, 2026 at 08:45:23AM +0100, Christian Loehle wrote: > > On 6/23/26 08:20, Vincent Guittot wrote: > > > On Tue, 23 Jun 2026 at 01:55, Ricardo Neri > > > wrote: > > >> > > >> sched_balance_find_src_rq() avoids selecting a runqueue with a single > > >> running task as busiest if doing so results in migrating the task to a > > >> CPU with less than ~5% of extra capacity. It also unintentionally > > >> prevents migrations between CPUs of identical capacity. > > >> > > >> When CONFIG_SCHED_CLUSTER is enabled, load should be balanced across > > >> clusters of CPUs with the same capacity. Allowing migration between CPUs > > >> of identical capacity is necessary to meet this goal. > > >> > > >> Use arch_scale_cpu_capacity() to reflect architectural capacity, excluding > > > > > > capacity_of() reflects not only RT and irq pressure but also thermal > > > pressure or system frequency capping. > > > If dst cluster is under thermal mitigation but the source cluster is > > > not, we probably shouldn't spread tasks across both clusters. > > > Have you considered using get_actual_cpu_capacity() instead of > > > arch_scale_cpu_capacity() ? > > > > Replacing arch_scale_cpu_capacity() with get_actual_cpu_capacity() > > would make the == comparison below very unlikely to be true FWIW. > > Yes, this is what I thought too. I did not try with get_actual_cpu_capacity(), > though. Perhaps on Intel processors it would work since rq->avg_hw.load_avg > is not used, IIUC. I am not sure about cpufreq_pressure. I need to check. > > Still, it may work for Intel processors but not for ARM ones. > > > I think it's fine like that, I will prepare a follow-up anyway to make > > it work for our "almost equal capacity" cluster systems and then also > > consider switching to get_actual_cpu_capacity() since we include a margin > > anyway. > > Great! I confirmed that does not use rq->avg_hw.load_avg nor cpufreq_pressure. Hence, get_actual_cpu_capacity() worked for me on Intel hybrid processors, but it would not on other architectures. So perhaps we can stick with arch_scale_cpu_capacity() for now? The series from Christian will add a margin, making the use of get_actual_cpu_capacity() feasible.