From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) (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 9402B47DFAB for ; Wed, 5 Aug 2026 16:04:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785945896; cv=none; b=D+OfmWYEUvNau41XfAOcQRSlFLbiWBRwQG5Pz4F7XGjgoPMLNspOCYZKt/goDva6kzhmvsAUx7rhusy2TWhbFXtBt6FHn78plKZ53cY4IKneCERMz+0mrjeWMvazeN3lsvKbS48DotUKvik+Xd9IFTOQ4QX+WKjKza/oc/lAz5k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785945896; c=relaxed/simple; bh=paAY1XtX+4+2p0AJnvvlvldFv8ZHBmA7kjG1zYKVztU=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=FDzSs/Lk2n2uncO97vrtM20qhWv8tK6WsvdivfLHNz57kUCyUa4sfDKw1QX+wkFFkMHYvZnpI+QMm3N1Daalcwu5k+ETmmXGqJJbUQ+RoZp8/9khcetRxf1LawrD1ynkAIE8kbyKm/eNh2vVdjhpAqn0+BjJ44jPRtloNUNIgvc= 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=MA/yGECx; arc=none smtp.client-ip=198.175.65.12 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="MA/yGECx" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785945893; x=1817481893; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=paAY1XtX+4+2p0AJnvvlvldFv8ZHBmA7kjG1zYKVztU=; b=MA/yGECx+/UdT6E8WUVZ8g2PEO1b+GXZ/sSRnUON0NL2Y2uKW2HqZMxl imyulruxj5E15tjOkDtKjVwvLZD7lFCtNaof6Sl7gWcPP7ACMNP3YyhHU dy6Eb5Q2STDsluqemXkPVHAnFagZ8xiuheED/VFT4qZyDXbEJ4lc/UHAb mWcXnzmDbWkdGNuLhWgqw6raGfM6E9ULBjSr/QoYcmDhQ9r4MAJ8fpaOO uqGqtUjxjBgNtY3dyRzUbPorILuuvsHQ5yI/duDv9HgE5wvyPN9ph6V+j QlIl3f/g7Cx1Qhbo4D8kv2ZRy51pvnSqkFFa96hyCAHXdKF/Os9E/RdAd w==; X-CSE-ConnectionGUID: MkezDgPBSSWfEhS/I3mPFg== X-CSE-MsgGUID: 03lxHSVKQxOMC/qDlkUv4Q== X-IronPort-AV: E=McAfee;i="6800,10657,11866"; a="98033576" X-IronPort-AV: E=Sophos;i="6.25,206,1779174000"; d="scan'208";a="98033576" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Aug 2026 09:04:52 -0700 X-CSE-ConnectionGUID: 6gqR8KxnStqeMFSjSr23Zg== X-CSE-MsgGUID: jDoo2+wsQTiI81FjghICjQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,206,1779174000"; d="scan'208";a="265337472" Received: from schen9-mobl4.amr.corp.intel.com (HELO [10.125.109.47]) ([10.125.109.47]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Aug 2026 09:04:51 -0700 Message-ID: <033401d1699b4852fbfdd05140bdd56c7bca5f7a.camel@linux.intel.com> Subject: Re: [PATCH] sched/cache: honor migrate_llc_task semantics in active load balance From: Tim Chen To: wanglu15 Cc: yu.c.chen@intel.com, 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: Wed, 05 Aug 2026 09:04:50 -0700 In-Reply-To: <20260805023845.4040148-1-wanglu15@lixiang.com> References: <2b23308912135b92e8f10e1b8909c89d8b46f41b.camel@linux.intel.com> <20260805023845.4040148-1-wanglu15@lixiang.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 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_task i= s > > > > set because src_rq has at least one task, p1, that wants to migrate > > > > 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 balanc= e is > > > > triggered. It iterates over p1 and p2 on src_rq to see if it can mo= ve any > > > > one of them to dst_rq, and in most cases it succeeds in moving p1 t= o > > > > dst_cpu. As a result, ALB will not be triggered. > > >=20 > > > My question is whether p1 is guaranteed to be moved out in passive > > > LB. can_migrate_task()/migrate_degrades_llc() can reject p1 for > > > several independent reasons =E2=80=94 p1 pinned by cpus_ptr, p1 cache= -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 p2 > > > both present on src_rq. > > >=20 > > > Can we conclude that p1 and p2 never end up on src_rq together when > > > ALB fires? Or would it help to set up a simple experiment and trace > > > this path to see whether it actually occurs in practice? > >=20 > > With 2 tasks on rq with different preference, active load balance could > > pick the wrong task as can_migrate_task() checked in active load balanc= e > > will not consult migrate_degrades_llc(). How about the following patch > > 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 If we cannot pull a task from this rq for a migrate_llc_task imbalance=C2= =A0 with more than one runnable task, can_migrate_task() has already=C2=A0 rejected the candidates =E2=80=94 either the task preferring the dst LLC=C2= =A0 is cache-hot or capacity-constrained, or the only movable task=C2=A0 prefers the source LLC. Forcing ALB here would ignore that. We keep ALB only for the single-task case, where that lone task prefers the dst LLC and has no other way to migrate. I think this is the right thing to do because we shouldn't force the tasks to move when can_migrate_task() is already telling us not to. Tim