From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) (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 2F5975478D for ; Wed, 24 Jun 2026 05:15:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.9 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782278162; cv=none; b=bOMyeQY9V3RP8NDM2xACkSaNVkAuv94/OgNb2jHwZwJ3z/ohI+2FfMPljnk0JQ/H37E8oTf0VII4HXXf9ak8m9TRwwhk/Xv5Ho1C0YdG46tuTNo22Q0pYlCrvV9vFw2GwWoYndLvvHJKQXoD1y7yJr28f80hV6Pmvw42AdkIeqQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782278162; c=relaxed/simple; bh=lK+tHrSzqUI0x05CzqtDJASgz91OpCPtBiHWyuSIU4c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DDG5BZBGGG1QwyafutevoNP/93hohPP7IuEs8OvW/5zwOLY0two+MOgUyeeo33hMwY681e6LDV7qUNgj3fQ5EH6bw4hfUkwMBRylhWyE/0Zj/vPON/Pnuk5YhCS2ilS3w8B4Z4EwrDAqjdgx6XNcmQjiG5wrW7pP7g6I2uAN6Nw= 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=Ge/6G3uZ; arc=none smtp.client-ip=198.175.65.9 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="Ge/6G3uZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1782278151; x=1813814151; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=lK+tHrSzqUI0x05CzqtDJASgz91OpCPtBiHWyuSIU4c=; b=Ge/6G3uZQWbZQ2bj+hWcvai25IqRoC7/zfzknB1P8lNmYoir0iS5KFiU iKhfg/TZQO5CN78GDEpvdL5wr8CyKENaKZRJJ1DQ5rJPduLM1KcjG3tfV 6AMCAVsYVp7jAWcxlZKayGudMqoCn7OjTzDRsD/ailfw8mq3sMuLqxXoM eO9A/Y4X7VYvyqangby+Fx7iQyRw2Uu/3v+3WeP5mx/sNJhZ4H6Q9PrvE un4yA/DQusVk06Wf6Cn8PykPZd/DiNWiVaAzXmPPiZflGN8jxvH2XqTCo s+/EZWSFdJjhp++bUL7/m2aQlqnK+5pQkne4XFnMG1JB5mZY0ZhA4o+Ct Q==; X-CSE-ConnectionGUID: 2xwl9OWORUmjVsMqByC9lQ== X-CSE-MsgGUID: +sh3DcRLSdeg/Kp4AujbMA== X-IronPort-AV: E=McAfee;i="6800,10657,11826"; a="105825128" X-IronPort-AV: E=Sophos;i="6.24,221,1774335600"; d="scan'208";a="105825128" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2026 22:15:50 -0700 X-CSE-ConnectionGUID: is6++zUGRC+9UmlHIcwOMA== X-CSE-MsgGUID: bhxzVCPiR/q/wFHLUb0FgA== X-ExtLoop1: 1 Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by fmviesa003.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2026 22:15:50 -0700 Date: Tue, 23 Jun 2026 22:25:14 -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: <20260624052514.GA16859@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> 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: User-Agent: Mutt/1.9.4 (2018-02-28) 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!