From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) (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 DDCCA3A962E for ; Tue, 4 Aug 2026 08:30:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785832241; cv=none; b=e0fidjTOOR34nu6SjRLA9NEigKfOxEcfyTHG95dGHITvZjyA/+AGK4FPOvzeQeYFZ017u6InPCKhInbMP/YFxg1MOwFxv5XoGrCqW9XkvNscflDRYnvxCubE3QWDjA32a7VXj+G+iMMQM97gYCxtq04Ge2YNhqKQlX3gKDr7Sio= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785832241; c=relaxed/simple; bh=ZhHxj2FSCnRw9cvh2RFfHpCQrfY37vJk8FNLsAFu/Cg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=X53OZGKsCKWiXPDfRmTu5Q+eQ0g0OP3losnWGlCCWYZX0+5NoMtqxqfbtjZjqbv7kyIcdm94UfNMIyy3dOYfHyttKXrnaVcvXUAx5UK0DEIKAANZKvixkNaYcmXl4qlIjO2qMiYIfvq7rX1amZDkd6+7s2OYml3e1gf63NL1xhQ= 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=NNj6ORcj; arc=none smtp.client-ip=209.85.216.42 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="NNj6ORcj" Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-3900e39d935so221459a91.0 for ; Tue, 04 Aug 2026 01:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785832239; x=1786437039; 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=N+TOofB6yai2W/WdO+rM5WMTPBQboYZqzSFycXWCbso=; b=NNj6ORcj6zq/pseSly/upNQdfWbZz/bl4+e3RQNRP6UJSGanvTqsgh5dpN/ewa0QVX zZ35qRS6zOqfENq/XAbMtNI5m4A86i7FJC+NaDKtTIZOMbFz/xBmBmGnE5ZZPe/8ZjVH IpMdCkkkWZMxOWXlm7m8y7HIk2hoE5MF6GA5E/eAVGtS52GEwGItcZg4sDpGy2AdEbSR eb3NV1eXkpaahOJQZsXPueX2bO45295+GPFN9PtfL1tMOVEgqnYVLZ/i3ZTdqTafKT70 7iFG8NbwhfIpqtTXiLvpgU0qVf8gNtMT49Yx5mTLD+VND4Ko7kiwT59ijX2FTZicZUTv IG4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785832239; x=1786437039; 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=N+TOofB6yai2W/WdO+rM5WMTPBQboYZqzSFycXWCbso=; b=dVxy6V1maLqv+zkev03uKfxa9w8sOuce0bgeIsaekQz+SrNXEMlu58GZhz8BoXuhLM N/35tQ/Ln8Y/N50+s/PRvKqu4kqX/99k/gkIoMPFco8DKplGpxGv9VbSURSXz+5HHg3o wK11nTpKXy/a0mVFasBP3QRcWHnAevQ1Sjpzr+4NxPEqZTaju7SRHvxJIaIpqQtb/mMc zZDs51+sRPX71kGn3FMlzaX4z5tGwTykfwGzXR0Kt84OiJFUpJhU8/tcspzkCakTe/hp YhnIbeoWBRFssfBQdO4apN0rUPAxGs7Cq+I9fNHSzquAXkW+sAzZv1BclKhrVr8pGR1C 0pDw== X-Forwarded-Encrypted: i=1; AHgh+RpRBGw4gPTt/H8q7xUYzL8KuhxVClBhTnXZswLWE0HGNpaSKloQjOcNX53BlbFKVW8ysHZdl/DJ0IKjANY=@vger.kernel.org X-Gm-Message-State: AOJu0YwBzGUvFv+m7f+Gm6uLslhXUPQNqK7aqJgpdVn+oVwBaWm+kIUi 4CV3/0l5ILoC9d4Gx0mCIrvoJsaApWq4+Ijru8nsP9CiKavZinH8JePS X-Gm-Gg: AR+sD12N1FgujSS6BWTtCT34XRqRx13kexsxtEbzmPQ87WW9ZOa0kjCTKXsO1SQ8ajd GdJwWlqG81Uqo0tOlvL0/H/JD4A2/QLcQ9g+TILnhB+t+sH9IpDNaxFhEL/3xJnwmAFSa7/Rvow 3aapx0uyXnDq/jgG6dqVh32MZHwqIaHphDofxugQEfZlEcdzbrVSvqxMoJR9btbgOZb8EDVPUzJ hT9qyGL8Ge9TGExV9P/IKqBCnp8ZW5kuknhSGe52YbzpQlmBBn4owvqj4sWFkq2Q06pSLyct+4Z RVF5FqL8DN6AzbsHRoJ0oUOPsxFcIhXH1pelOxy9AEausnIxSQ2NWkZ2TgzkdSc3Nif/XYWVxl+ lV4TBLZMIbrauXS0IeA354zMi+458i6TJbeCl7Kd1EY+jYqNGu0pDIgoIJPnkilaB4eOg5MKmhc WGzuxxBP7/HwjpnWgMUau4bOq561JShsCvo+W4gbvlnW3Gg5/9G3b/lXLSuBAauzp50GrYCgROx ZHWaHQE8i53I0eE2KN9mzLHopA= X-Received: by 2002:a17:90b:1808:b0:38e:fea2:df53 with SMTP id 98e67ed59e1d1-38fbc40df10mr12359894a91.4.1785832238996; Tue, 04 Aug 2026 01:30:38 -0700 (PDT) Received: from PC-2B0BA19500175.company.local ([210.184.73.204]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-38fec37f5d9sm959223a91.17.2026.08.04.01.30.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Aug 2026 01:30:38 -0700 (PDT) From: Lu Wang To: tim.c.chen@linux.intel.com Cc: bsegall@google.com, chen.yu@linux.dev, dietmar.eggemann@arm.com, juri.lelli@redhat.com, kprateek.nayak@amd.com, linux-kernel@vger.kernel.org, mgorman@suse.de, mingo@redhat.com, peterz@infradead.org, rostedt@goodmis.org, vincent.guittot@linaro.org, vschneid@redhat.com, yu.c.chen@intel.com, Lu Wang Subject: Re: [PATCH] sched/cache: honor migrate_llc_task semantics in active load balance Date: Tue, 4 Aug 2026 16:30:27 +0800 Message-ID: <20260804083027.2583285-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, Tim. On Mon, 2026-08-03 at 17:10 -0700, Tim Chen wrote: > On Mon, 2026-08-03 at 18:02 +0800, Lu Wang wrote: > > Thanks for the review, Chenyu. > > > > I got interested in CAS because it strikes a good balance between > > generic CFS load balancing and strict LLC/CPU affinity. > > > > My understanding is that migrate_llc_task encodes the target > > direction of the balance pass, not just "ALB was triggered by CAS". > > alb_break_llc() only vetoes ALB when every task on src_rq prefers > > staying put (nr_pref_llc_running == cfs.h_nr_runnable); once tasks > > have mixed preferences it lets ALB through without checking which > > one gets picked. active_load_balance_cpu_stop() then walks > > src_rq->cfs_tasks in reverse and takes the first task accepted by > > can_migrate_task() — with multiple tasks on src_rq, that's not > > necessarily the one whose preferred_llc matches the destination. > > > > My patch threads migration_type through to the stopper and, only > > for migrate_llc_task, rejects a candidate whose preferred_llc > > doesn't match the destination LLC. > > > > Regarding: > > > this helps the case where the task is the only running one on the > > > src_cpu > > > > If that single task already prefers the destination LLC, my check > > still returns true, so this case is unaffected. The disagreement is > > really about what happens when it does not prefer the destination. > > That comes down to how we read the semantics of migrate_llc_task: > > > > (a) "migrate a task toward the destination LLC selected by > > calculate_imbalance()", or > > (b) "this ALB was triggered by CAS's LLC-balance logic, so any > > generally-eligible task on src_rq may be pushed" > > The policy of when to break LLC preference locality whether it is in > regular load balance or in active load balance are both encoded in > can_migrate_llc(). Sometimes when an LLC is overloaded, you may > want to move the task off its preferred LLC. Moving a task off its > preferred LLC is not always wrong. Looks like you patch > stop that with migrate_llc_task_wrong_dst(). > There is a comment section above can_migrate_llc() to > explain the policy details. To clarify the scope: my patch only adds a stricter check for the migrate_llc_task type during migration. llc_balance() triggers this classification as long as there are tasks whose preferred LLC is the destination, independent of load or utilization. So it sits at the end of the balancing priority chain. The comment above group_llc_balance's priority assignment, which you wrote, says: "The priority of group_llc_balance is lower than that of [other types]... This is because group_llc_balance may exacerbate load imbalance." This makes clear that group_llc_balance was not designed to correct load imbalance — it explicitly acknowledges it may worsen it. For the other migration types that do address load imbalance (migrate_load, migrate_util, migrate_task, migrate_misfit), my patch doesn't change their logic at all — the check only fires when env->migration_type == migrate_llc_task. Is my understanding incorrect here? Wang