From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) (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 2A8802D5C83 for ; Wed, 10 Jun 2026 03:23:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.16 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781061823; cv=none; b=U19rjjH19eKIY7OC1884SlRr23nHCXw5CIxyj4UvWvW/M7n9av3KVbC5nuTp62XpZewJKZc+gytjY64PEagrODlvibXqCCnziZ6BKXU1jblsKVR47tTgtJyVzlKIKedlt4EI6v8xj9AT1F6eAavE/53Bjr6sgMADPAvfkgnxkco= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781061823; c=relaxed/simple; bh=XwpRJ26Y61orhme8NjT5CF3Bis0hpCyX8Lepp2dm8FM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pgXINRu+Zx3/63JdN+85l2FULIdlV5c3Z+dZCHdzDYF/WttnMNutVldIU0tF6Goq0qPdq9pCCiw5vb1rRdMXwhZU33NprkCQ7Ert8X3zsK9vZIbdwAqnGQHXtgzlFtTKsbVq0i27xpTB7mt5Jxs38qpuJd2w+q2hgznbMmiqLsw= 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=UP0sMfLA; arc=none smtp.client-ip=192.198.163.16 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="UP0sMfLA" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1781061822; x=1812597822; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=XwpRJ26Y61orhme8NjT5CF3Bis0hpCyX8Lepp2dm8FM=; b=UP0sMfLAaf36dyLxiotSuRHhbJSG5y1ELUauNQ3oK/6JSpInGb7uiIOR 9zYKGBg9e9KKE6BmsrEnZ2VH1rhg3cF6kcLCcDHxHGmIAHMl5whNth8xC 4EFP2znBxWSw/llcCBqx0S17DmbMZLpMpgHHs7dTN6yT/Vs0Pvgme7sOS RcN/fy4D3VGkuGyYSFG3bE0e8gFSxAzUNi83jFIITaHnkGFcqMaJ3EiJF DrBMGc0jxm8V4OFeOPO8N1UIkMzV+E8tfjKHbyToex7YJYeJ1GoSo4hiD 3en9yVS9fxsyXebHfXacaoVLbPxjuoIrDXvrW9OzMFVBxOcvdfdNnT/Yr A==; X-CSE-ConnectionGUID: DJyc7L+9RmuguJHvGYnVMQ== X-CSE-MsgGUID: xRpJGmcQS6mu2qdcyxMZCA== X-IronPort-AV: E=McAfee;i="6800,10657,11812"; a="69379581" X-IronPort-AV: E=Sophos;i="6.24,197,1774335600"; d="scan'208";a="69379581" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jun 2026 20:23:41 -0700 X-CSE-ConnectionGUID: IYACxFSjR8SWW8QJZrH/6A== X-CSE-MsgGUID: nbmbSzbRR5qU+fkryKJJIQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,197,1774335600"; d="scan'208";a="245195151" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by orviesa010.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jun 2026 20:23:41 -0700 Date: Tue, 9 Jun 2026 20:32:50 -0700 From: Ricardo Neri To: Christian Loehle Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Tim C Chen , Chen Yu , Barry Song , "Rafael J. Wysocki" , Andrea Righi , K Prateek Nayak , Len Brown , ricardo.neri@intel.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 1/6] sched/fair: Do not skip CPUs of similar capacity with busy SMT siblings Message-ID: <20260610033250.GC30647@ranerica-svr.sc.intel.com> References: <20260608-rneri-fix-cas-clusters-v4-0-1526711c944c@linux.intel.com> <20260608-rneri-fix-cas-clusters-v4-1-1526711c944c@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 Mon, Jun 08, 2026 at 02:50:38PM +0100, Christian Loehle wrote: > On 6/8/26 13:57, Ricardo Neri wrote: > > When picking a busiest CPU with only one running task, the function > > sched_balance_find_src_rq() skips candidate CPUs if the destination CPU has > > less than ~5% extra capacity. This condition only holds if all the SMT > > siblings of a CPU are idle. > > > > SMT siblings share the computing resources of a physical core and this > > results in reduced capacity if more than one sibling is busy. > > > > Skipping a CPU as described would prevent the load balancer from pulling > > tasks from a scheduling group previously and correctly identified as > > group_smt_balance (i.e., one with more than one task running). > > > > Do not skip a candidate CPU of similar capacity if it has busy SMT > > siblings. > > > > Signed-off-by: Ricardo Neri > > Nice find! > Reviewed-by: Christian Loehle Thanks! I will make more changes based on feedback from Chen Yu and Prateek. You may want to reissue your tag after that :)