From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) (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 08FB733DEF7 for ; Thu, 6 Aug 2026 16:21:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786033273; cv=none; b=elx/ZU8gb+AgapUiia7dJ/fwHonJNni7sGwHsKjZCVXuq7R66bZM6jOdXY7kBKGzLTcI0Q9E8PKMkN666KwGMo+Dd3rkuH30TD5zCq8Fj0orWA3M0tW0d6reF56VxdrfEFMtqcWsYpxCf+bD3RRyl/46MN7IEBvNvKKXRDRnCgI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786033273; c=relaxed/simple; bh=v5+bbI8OI1E+fveqV9ZxMlwTZZy3XVRhEp0ijLPh+FA=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=sjA6SHzDIU9M+Gxvd1U1c+O3VU1xoHHwZGdqn+ryT/IkcUBNAWcwQ81JcL/VUroBwSF1eMshVlwPRl+nsNQSGRB2N58KqWCarjLFZVC/q05pegi04E/Vo8wq73DAYUX1SoYI9I01ZLvanD2MrNi7Zt4feFxcMEkcRAMIcjlUbKM= 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=ewnzahlg; arc=none smtp.client-ip=192.198.163.18 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="ewnzahlg" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1786033272; x=1817569272; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=v5+bbI8OI1E+fveqV9ZxMlwTZZy3XVRhEp0ijLPh+FA=; b=ewnzahlgY632piTAruABAuofT52tmcxTJRSWqrfa+L4jVaYlf00pdTsG U+sHQXVJrx+CWp6JKGpPRCZxkrPzOU6D3WWzR5p+M8edk5qn5BdnkzUXL RwVPhUta7omfB7GNzmw7yotOH0zUSHEPOVg8KHNZ6IYJTnxu5BoLjGjQx YeVKtDET0VWr+m63fQvdPyXFOicIt5eEGlfp2m81AwAsxc4wvn/17s5l9 2izxPRTitaAW5MuNtxIzI0F9Jhc9eU2h4bXX3xBSgziAa4ug0RLWtmO/O hzLVmZanCKd1UrfMPt7hpSMNx1baB0zNkQLLX1u4OCh073JIPAm5ww1Yh g==; X-CSE-ConnectionGUID: 5aILZNLJTdaKg4je633Ftw== X-CSE-MsgGUID: FyxM4me8Sn2xS01WEP3Yyg== X-IronPort-AV: E=McAfee;i="6800,10657,11867"; a="85756340" X-IronPort-AV: E=Sophos;i="6.25,208,1779174000"; d="scan'208";a="85756340" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Aug 2026 09:21:11 -0700 X-CSE-ConnectionGUID: WFh1+R/sSA6V1DVwwJBNNQ== X-CSE-MsgGUID: /KAUje7JQLG4rg7pEum7Dg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,208,1779174000"; d="scan'208";a="261626590" Received: from schen9-mobl4.amr.corp.intel.com (HELO [10.125.109.116]) ([10.125.109.116]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Aug 2026 09:21:10 -0700 Message-ID: Subject: Re: [PATCH] sched/cache: honor migrate_llc_task semantics in active load balance From: Tim Chen To: "Chen, Yu C" , wanglu15 Cc: peterz@infradead.org, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, kprateek.nayak@amd.com, linux-kernel@vger.kernel.org, chen.yu@linux.dev Date: Thu, 06 Aug 2026 09:21:09 -0700 In-Reply-To: <266b2607-45a6-4e36-820f-85b93e5df33d@intel.com> References: <2b23308912135b92e8f10e1b8909c89d8b46f41b.camel@linux.intel.com> <20260805023845.4040148-1-wanglu15@lixiang.com> <033401d1699b4852fbfdd05140bdd56c7bca5f7a.camel@linux.intel.com> <266b2607-45a6-4e36-820f-85b93e5df33d@intel.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 Thu, 2026-08-06 at 00:43 +0800, Chen, Yu C wrote: > On 8/6/2026 12:04 AM, Tim Chen wrote: > > On Wed, 2026-08-05 at 10:38 +0800, wanglu15 wrote: > > > From: Lu Wang > > >=20 > > > Thanks, Tim. > > >=20 > > > On Tue, 2026-08-04 at 12:42 -0700, Tim Chen wrote: > > > > On Tue, 2026-08-04 at 23:07 +0800, Lu Wang wrote: > > > > > Thanks, Chenyu. > > > > >=20 > > > > > On Tue, 2026-08-04 at 16:17 +0800, Chen, Yu C wrote: > > > > > > Yes. Besides, if I understand correctly, I suppose Lu Wang was > > > > > > referring to the following scenario: > > > > > >=20 > > > > > > src_rq has 2 runnable tasks, p1 and p2. p1 prefers dst_rq (dst_= llc), > > > > > > while p2 prefers src_rq (src_llc). In this case, migrate_llc_ta= sk is > > > > > > set because src_rq has at least one task, p1, that wants to mig= rate > > > > > > to dst_rq. In ALB, can_migrate_task() found p2 and returns true= for p2 > > > > > > thus moves p2 out of its preferred LLC. > > > > >=20 > > > > > That's exactly the scenario I had in mind. > > > > >=20 > > > > > > Firstly, before ALB is triggered, the generic (passive) load ba= lance is > > > > > > triggered. It iterates over p1 and p2 on src_rq to see if it ca= n move any > > > > > > one of them to dst_rq, and in most cases it succeeds in moving = p1 to > > > > > > dst_cpu. As a result, ALB will not be triggered. > > > > >=20 > > > > > My question is whether p1 is guaranteed to be moved out in passiv= e > > > > > LB. can_migrate_task()/migrate_degrades_llc() can reject p1 for > > > > > several independent reasons =E2=80=94 p1 pinned by cpus_ptr, p1 c= ache-hot > > > > > with nr_balance_failed still below cache_nice_tries, or > > > > > can_migrate_llc_task() returning something other than mig_forbid = due > > > > > to capacity constraints on dst_llc at that instant. If passive LB > > > > > rejects p1 for any of these, ALB is still triggered with p1 and p= 2 > > > > > both present on src_rq. > > > > >=20 > > > > > Can we conclude that p1 and p2 never end up on src_rq together wh= en > > > > > ALB fires? Or would it help to set up a simple experiment and tra= ce > > > > > this path to see whether it actually occurs in practice? >=20 > I see. It is possible for p1 and p2 to coexist on src_rq. Previously, > I thought that if task migration failed due to CPU affinity, then dst_cpu > or src_cpu would be changed because of env.flags & LBF_DST_PINNED or > env.flags & LBF_ALL_PINNED. So ALB would be skipped. But a more common > scenario seems to be when p1 is the running task. Then can_migrate_task() > will gate it anyway. That is a common migration failure. >=20 > > > >=20 > > > > With 2 tasks on rq with different preference, active load balance c= ould > > > > pick the wrong task as can_migrate_task() checked in active load ba= lance > > > > will not consult migrate_degrades_llc(). How about the following p= atch > > > > to fix this issue. > > > >=20 > > > > [...] > > > >=20 > > > > + if (env->migration_type =3D=3D migrate_llc_task && > > > > + env->src_rq->cfs.h_nr_runnable > 1) > > > > + return true; > > > > + > > > > return false; > > > > } > > >=20 > > > Your approach is simpler than mine =E2=80=94 it avoids threading > > > migration_type across the CPU stopper boundary and doesn't need any > > > new rq field. > > >=20 > > > One thing I'd like to flag, IMO: this approach skips the ALB path > > > entirely for migrate_llc_task whenever more than one task is > > > runnable, deferring the fix to the next passive LB pass. So it > > > trades "delay" for a simpler implementation. > > >=20 > >=20 > > If we cannot pull a task from this rq for a migrate_llc_task imbalance > > with more than one runnable task, can_migrate_task() has already > > rejected the candidates =E2=80=94 either the task preferring the dst LL= C > > is cache-hot or capacity-constrained, or the only movable task > > prefers the source LLC. Forcing ALB here would ignore that. >=20 > In passive load balance, if there are 2 tasks, p1 prefers dst_llc, > and if p1 is the running task, then p1 can not be migrated to > dst_cpu in can_migrate_task(): > if (task_on_cpu(env->src_rq, p)) > return 0; > and in this case we might have to rely on ALB to migrate p1(not > ignore it) Considering the case above, then what Lu Wang proposed is probably the bett= er option. Tim