From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E5B9D370D5E for ; Tue, 4 Aug 2026 15:07:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785856065; cv=none; b=hFTW8JZ5jK7/GsmNxSy9f3stG19/F09pNOReNGmOTBTm2oWHfsMBhSfoaYhPcegH1PsAdlKkmZN7K/CDt9PoraVFBd4yMxpqrmvI8vJedDg/eZoFh1yVsmBgMFiH0FTQxzmhOIA04rZO084o3IC0Yx36C7cbQHRLlWMbShoq77k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785856065; c=relaxed/simple; bh=iYWsqtkA4ZnDnUnOXuVW8B/lzH+kdxqxXvbOTEDsg3s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=pmrJUUyrYR/jY0dTJ5oRqMPc7ZPj3vUuG+17vw3PngkfBx7c3VTUC556zymeK4uclbt1Us6K0BrXtzZG5pKyCIfDcMGR6N1xuf1nEeIaYffITZxiZyQMK9ApjmCQusJhCW6/bXrPxAfUGUHcnvD23QyaDP+qF42DKhfWbw97mEo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=lcaJWeTa; arc=none smtp.client-ip=209.85.214.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lcaJWeTa" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-2cc97653887so52522035ad.1 for ; Tue, 04 Aug 2026 08:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785856063; x=1786460863; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=iYWsqtkA4ZnDnUnOXuVW8B/lzH+kdxqxXvbOTEDsg3s=; b=lcaJWeTa8w1FSXXzKE7tDMwuy+jt+8KqsxcDTVA79UoswKhSVgQS1CTcQX/xib6t4G Y/GBN1kjTd38X2e/hg2NWVHAXlu9ailfchuBQV11dK2qzqqkWsHw2lnubTO/mZkRVXCG Hli/3P0Vi7254T7uoADNPiCa+zUxwFa/uAYCjTvdtw68+f6lCjr+J+xNjzuVYT9JXGJE g73aWg1MMmLXLncuCHs+DWqLS4mZHFUM2rkUHNL4nvNJZt/N3X28Dji8AU/WiwGEkXr6 eQgEn+cJa79zVUAfuZD04afmYTR98my8lVQ2EOLFGHnXVr6BQK+K11AN7aU5+e8Duj9d Ud5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785856063; x=1786460863; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=iYWsqtkA4ZnDnUnOXuVW8B/lzH+kdxqxXvbOTEDsg3s=; b=MLPri/OQ4U9OJncyiY/7XzXDx7oqZvfZI3u9KXfuIVANM9Ww+H7hzaLFhgzAED2pa8 GIvhitQ/gC/Yp1hAQF6yNB6rUdXmca7DlvFBofGurXSKOl6M+EPfNF6LEXCp4OoR3kc3 3vjZRhmVhW8W8q31Vb2DRcoChzB+8ELauI4ZDewNQtVhs8yprtUZNIpVLv/N8xXYcbx/ YToEYHfNERjHTLGIR6VevD83DxTjKROCn46fUKAiCFAtxd9rvgudF77MykuUinyEJU95 EjLZ6vGG99yRpYgS8a6y2+5b/L0qzX21rtUo48N1QyCisQ6dZZhrITDJPTIuuWloG2cs 14+w== X-Forwarded-Encrypted: i=1; AHgh+Rqv4tSN8GoQwg7rM3ELeiEm3VWSN1JyX+982XT6WPQIdxsyZAwei8R0KlnF7GdaP4kL3GlEBYQ3dwyYV+s=@vger.kernel.org X-Gm-Message-State: AOJu0Yy7oUfgBQeD8goTpbY2MstbR858n8OKdBu7MQwYJTpJmjnNOndg YNKp7B2lwwBK636jDhCet1QTiy/S0HpkKos8n3leB6myk0boU23WL0VN X-Gm-Gg: AR+sD13NDi7RDIxPvt7/OOl7MFhFiihy6QAs6NAQjFc4AKgXj4plrQlEK3mDxA0Tc2S r3+r2/PfsrJQAk4rn4Ml9Zz7OCLEo3eES6OGZOR14RAIMEOUNaZE2tAtePBCnNSsJXjDg08VaHO 4gpMxENnEdSLcizYC6y2qC5HXlRl35MbfCsPSK5QzELMqE31lkpV8XyR3ZEw0CI9Vbnfz5jkUmq VhlwnzgC/gZ4LyM+BWkLeZoKl3XuFag18eFo9FWVlRted74Z66lP2JZehdAJiuaPL9ge4++SheM 1v5bCohZW7cZQfgnXqR5zEJs1Rm73p3bqIvi1Zc+itipjhWD5J/WFvA6hHTNlLei62fekvsnk2u l3ifTqQatReBdKWmAuUk0fat7qDN6nOXMt/GdIYm+tKn6Mm87u5bkxH97zfhPU23i0M2obqhT9U FG4Zb+cYN5yhVjIvCmfiq5AwE4u4KupQRC8ravu2W7ZmU0Rwg6fb+XvvwjfLgtYoFSgoBK1Y/My RYWXeOBm+ogjF8= X-Received: by 2002:a17:903:160c:b0:2ca:c84b:c4a4 with SMTP id d9443c01a7336-2d05246fcf8mr149720515ad.28.1785856063154; Tue, 04 Aug 2026 08:07:43 -0700 (PDT) Received: from PC-2B0BA19500175.company.local ([210.184.73.204]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d0a9f8fb4bsm9365355ad.5.2026.08.04.08.07.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Aug 2026 08:07:42 -0700 (PDT) From: Lu Wang To: yu.c.chen@intel.com Cc: tim.c.chen@linux.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, Lu Wang Subject: Re: [PATCH] sched/cache: honor migrate_llc_task semantics in active load balance Date: Tue, 4 Aug 2026 23:07:33 +0800 Message-ID: <20260804150733.3406828-1-wanglu.priv@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: 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=UTF-8 Content-Transfer-Encoding: 8bit Thanks, Chenyu. 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: > > 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 is > 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. That's exactly the scenario I had in mind. > Firstly, before ALB is triggered, the generic (passive) load balance is > triggered. It iterates over p1 and p2 on src_rq to see if it can 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. 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 — 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. 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? Wang