From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (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 2FD65448B8E for ; Tue, 28 Jul 2026 14:26:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785248810; cv=none; b=XYBHKyH3U7JtPBciBexrcJUQI/g1IzQqgac4L7DI9wH5x+YMMQE1zprB6mvNG4IFOiITNFUltjpznI0bXVOg51rBlbB2Aetzg0hkY+NNbAqHH2IrUU02Rd+dy8hbXWrMIrN7ki8Ako/ekht7Xqq+Q5zqH1emClMFSf6Rve8kG+I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785248810; c=relaxed/simple; bh=r3ueamCqF+OjUwNjwstTdooXP+2uZqkEbBD1rgFYkmY=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=E7H3gnrf36EQtNmGDIhSWREPqQYcJ1Qwx+ZGZz/z8OOUb/HHJW3Hn+jW3P1IeJipjKsYzB4vTdwGHUqD/Rkt83GZwrndVXd/sATx5OhEaD+/MQrmIvz6XzKljyNOaEMnbffNU1H+zAIkBqpAj65cIBEBzorWIAES13F0jrieduM= 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=DBPAO7V6; arc=none smtp.client-ip=192.198.163.10 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="DBPAO7V6" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785248808; x=1816784808; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=r3ueamCqF+OjUwNjwstTdooXP+2uZqkEbBD1rgFYkmY=; b=DBPAO7V6VrfbYMA/+oBYG5JLELSb7Tfu+CAlEAWCC/K2TFwFhfGENW4o tkx/i+Lyd+99aBr3UkH0agqpT39F32vvY5uUuhU046LRnnMJvW5rjJd3Q WgbO8k4rC0ciZuPUdkWt7VwgMHp3nAZ5zfPyqhxylsn4hg+Lvmpd+vLtU vqi+zR3x8JsF2VivQOPFh3vUUWRGzqOleu5RLdf4NMS6yFZAWVDI1Q00N VF4TLTl/ef9TIkA8pys2YyK06WQkQqOPORBWz0Mo00WQSJERkL+Llw516 BmV3iLevqzm5iv722koyn1SVcwQ56q/g1GgOGFCpR7/Dtwzk2an47iMHe A==; X-CSE-ConnectionGUID: IPFkIZgETo2rTkxEKeG8Eg== X-CSE-MsgGUID: QbBGpmEpTfe8ZXqVJa6U1Q== X-IronPort-AV: E=McAfee;i="6800,10657,11859"; a="97207552" X-IronPort-AV: E=Sophos;i="6.25,190,1779174000"; d="scan'208";a="97207552" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jul 2026 07:26:47 -0700 X-CSE-ConnectionGUID: D8OxKlNMQae8RTB/A9B+vw== X-CSE-MsgGUID: 96JX3fhNTWu1vfAd3oa6Iw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,190,1779174000"; d="scan'208";a="257919282" Received: from schen9-mobl4.amr.corp.intel.com (HELO [10.125.111.108]) ([10.125.111.108]) by orviesa006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jul 2026 07:26:47 -0700 Message-ID: Subject: Re: [PATCH] sched/cache: Fix a thread aggregation conflict when there is one runnable task From: Tim Chen To: Zhan Xusheng , yu.c.chen@intel.com Cc: kprateek.nayak@amd.com, mingo@redhat.com, juri.lelli@redhat.com, vschneid@redhat.com, mgorman@suse.de, rostedt@goodmis.org, dietmar.eggemann@arm.com, bsegall@google.com, yi1.lai@intel.com, linux-kernel@vger.kernel.org, zhanxusheng@xiaomi.com, peterz@infradead.org, vincent.guittot@linaro.org, chen.yu@linux.dev Date: Tue, 28 Jul 2026 07:26:46 -0700 In-Reply-To: <20260727121730.2148901-1-zhanxusheng1024@gmail.com> References: <20260727064111.1350672-1-zhanxusheng1024@gmail.com> <70eb8310-bc01-4598-99e5-c53bf101a36d@intel.com> <20260727121730.2148901-1-zhanxusheng1024@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.1 (3.58.1-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Mon, 2026-07-27 at 20:39 +0800, Zhan Xusheng wrote: > From: Zhan Xusheng >=20 > On 7/27/2026 5:46 PM, Chen, Yu C wrote: > > I did a further investigation, and another reason it holds: with only o= ne > > running task, migrate_degrades_llc() is not what keeps the task in its > > preferred LLC. In the regular load balance path can_migrate_task() alre= ady > > bails at task_on_cpu() - since that task is curr. And in the active bal= ance > > path alb_break_llc() blocks it first: > >=20 > > if (env->src_rq->nr_running <=3D 1) > > return true; > >=20 > > so the task is not pulled back either way. >=20 > Thanks, that all makes sense. I traced both guards and they hold: >=20 > - Regular load balance: for the single running task can_migrate_task() > returns 0 at the task_on_cpu() check, so it is never pulled back on th= e > normal path (and for a non-running task the migrate_degrades_llc() -> > can_migrate_llc_task() =3D=3D mig_forbid check catches it). >=20 > - Active balance: need_active_balance() -> alb_break_llc() returns true > because nr_pref_llc_running =3D=3D h_nr_runnable and src_rq->nr_runnin= g <=3D 1. > What convinced me it is not symmetric - i.e. that the forward > migrate_llc_task still works - is that in the forward direction the ta= sk > does not prefer the source LLC, so nr_pref_llc_running =3D=3D 0 there = and > alb_break_llc() returns false. >=20 > > Good point. OK, let me add description in changelog: > > The adjacent SD_ASYM_CPUCAPACITY filter was left unchanged. In theory > > it should have been handled in the same way, but it is not clear yet > > whether any platform has both multiple LLCs and asymmetric CPU capacity= , > > so the asymmetric CPU capacity logic was not fine-tuned here and can be > > revisited once such a platform shows up. >=20 > That wording answers my question well - thanks for spelling out that > leaving the capacity filter alone is intentional pending a multi-LLC + > asym-capacity platform. My understanding is that 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 we likely will not get as much performance back from cache co-location vs the CPU capacity. So I think we can leave the SD_ASYM_CPUCAPACITY code as is till we come across a workload and platform that shows otherwise. Otherwise, Reviewed-by: Tim Chen Tim >=20 > Reviewed-by: Zhan Xusheng >=20 > Thanks, > Xusheng