From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) (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 6D2ED1B78F3 for ; Mon, 10 Aug 2026 03:47:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.21 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786333666; cv=none; b=KdJmdXYT8Ct5hRUcoChm+s9uwfYHD/4pGhnqBrP/Uop9JfW41udxd8zcREPfykpsG2xTNmTcXD/yaS1i/lvjIozx48g1+xfTMY4pI8XydaCh/RsgUxX42HM6ZhjNsTAVgY/gIYD5CdD71Ct6ALWltTZ1gf6XDUIUrQi7QX1JglY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786333666; c=relaxed/simple; bh=gfgo2ka7M5ClrRgexlcZxku0dM9L8bYkpFNRH7bWdqg=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=fjCoks0I7NVXaRt81s2fUFxpx+6kCyETU3gfUJcWmk//u2A7ii6BQ17tGik7EQE2MAsxHDai1AKycjKHf8tRGJaaClh0VeN/lD9VQzHEbTysOO7x/8R+WP52YDKeXjEBdnD3xCiPqgKD1GSBuHItDyFSzSKnqP5heYfqlT472+U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ZKRZsYY1; arc=none smtp.client-ip=198.175.65.21 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ZKRZsYY1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1786333665; x=1817869665; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=gfgo2ka7M5ClrRgexlcZxku0dM9L8bYkpFNRH7bWdqg=; b=ZKRZsYY1k6T8iRRfQm3c/wccjcqeUT28G/zhpw6quj6+rPAEA8PRDfAz eQH+1aLj0j16OKebWexb3vxtbmcKeN7wzxI6NgEGa7OHtEvVXShIU0whd /mgcJWUgjWtnV0X9FeAoOs+x7LXQijOKvwLPFUd96iKGfWtVwoHAOVvwN /FKPi3S8p6skijtFuiyFoVFBMOxAW7XipUWy5WnpRi5kNLbMBw3WZhg6O VSXV84EQqWs7hWaeuj7h/2NhNyGnNbBhVOqIbnCl1sd0GFANMUW9iiURL bTRVHw1Fz/bPT9Q5PTflO10NZLxzz/PlCGPWhMDot7tQqaMjWSNtKoWDd Q==; X-CSE-ConnectionGUID: P02r39E7SaGhjIxxpYh2sQ== X-CSE-MsgGUID: K2mthuMCQ/OvC76RyW1m4g== X-IronPort-AV: E=McAfee;i="6800,10657,11870"; a="86694168" X-IronPort-AV: E=Sophos;i="6.25,215,1779174000"; d="scan'208";a="86694168" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2026 20:47:44 -0700 X-CSE-ConnectionGUID: zp6VWy8DSS+Ar6Yd5H3wLQ== X-CSE-MsgGUID: YMEm46cDT6GlyjDZz4olqA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,215,1779174000"; d="scan'208";a="264905225" Received: from chenyu-dev.sh.intel.com ([10.239.62.107]) by fmviesa004.fm.intel.com with ESMTP; 09 Aug 2026 20:47:40 -0700 From: Chen Yu To: Peter Zijlstra , Vincent Guittot , Ingo Molnar , Juri Lelli Cc: K Prateek Nayak , Tim Chen , Valentin Schneider , Mel Gorman , Steven Rostedt , Dietmar Eggemann , Ben Segall , Yi Lai , Zhan Xusheng , chen.yu@linux.dev, linux-kernel@vger.kernel.org, Chen Yu , Zhan Xusheng Subject: [PATCH v2] sched/cache: Fix a thread aggregation conflict when there is one runnable task Date: Mon, 10 Aug 2026 11:37:42 +0800 Message-Id: <20260810033742.1688718-1-yu.c.chen@intel.com> X-Mailer: git-send-email 2.25.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Problem Statement: On systems with SD_ASYM_PACKING set at the PKG domain level (e.g., with ITMT enabled), the sched_asym() check in sched_balance_find_src_rq() prevents pulling a single task from a higher-priority CPU to a lower-priority CPU. This blocks migrate_llc_task migrations where a task wants to move to its preferred LLC for cache locality. For example, CPU 0 (highest priority) has a task preferring LLC3, but the load balancer on CPU 120 (LLC3) cannot pull it because: sched_asym(PKG_sd, cpu=0, dst_cpu=120) and nr_running == 1 The task remains stuck in the wrong LLC indefinitely. Proposal: Fix this by exempting migrate_llc_task from the sched_asym filter. The adjacent SD_ASYM_CPUCAPACITY filter was left unchanged. In theory it should have been handled in the same way. SD_ASYM_CPUCAPACITY is mostly used in the hybrid CPU situations (e.g. P-core and E-core on some Intel client CPUs). For those, the difference in CPU performance is pretty significant and it is unlikely to get as much performance back from cache co-location vs the CPU capacity. Leave the SD_ASYM_CPUCAPACITY code as is till a workload and platform show difference otherwise. Fixes: e4c9a4cb244a ("sched/cache: Add migrate_llc_task migration type for cache-aware balancing") Reported-by: Yi Lai Signed-off-by: Chen Yu Tested-by: Yi Lai Reviewed-by: Zhan Xusheng Reviewed-by: Tim Chen --- v1->v2: Revise commit log to include the reason why SD_ASYM_CPUCAPACITY is not touched. (Zhan Xusheng) --- kernel/sched/fair.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index d78467ec6ee1..e6e6fa84c9e1 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -12986,8 +12986,12 @@ static struct rq *sched_balance_find_src_rq(struct lb_env *env, * * If balancing between cores, let lower priority CPUs help * SMT cores with more than one busy sibling. + * + * For migrate_llc_task, skip this check: cache locality + * outweighs the asym priority. */ - if (sched_asym(env->sd, i, env->dst_cpu) && nr_running == 1) + if (sched_asym(env->sd, i, env->dst_cpu) && nr_running == 1 && + env->migration_type != migrate_llc_task) continue; switch (env->migration_type) { -- 2.25.1