From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (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 72E37324716 for ; Mon, 3 Aug 2026 10:02:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785751360; cv=none; b=svybYQurPFvexL2tt6xw5idUMFSSCL/fe7gPyR2NyDK96F3Pq57dYD22tmDoQ29IX8+oO2DAq/hmEodB4+DQhK9GUVvuj62S5p8pmDnl7jYbca96aaGtjspmoo/0IaeDtSIRL4ON3TEJvELbRKjgUoMcIHblwsc65b521Utlzwo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785751360; c=relaxed/simple; bh=jyme7ECH3nPo5wxzJVZCXJCVNrUWrUqu+scBkiZNM/U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=u+X4T35NzcoElF0nO+sFl0V9qLcEkb+fYumfmkPExoBVLRC95RK/LWCWN7pgoGAjJXCbnsoB6M1bMHQraAx8cYFPgj43BQe7YGQQVZgyUPhKr4WLSDFVx6VzONk/8BsgoTJzrJ5EIZ2XOeYEDj4/jf3JjvWlzjnnI7zEXYJ2hxc= 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=N1G5qA+O; arc=none smtp.client-ip=209.85.214.169 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="N1G5qA+O" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2caf228a910so22760865ad.2 for ; Mon, 03 Aug 2026 03:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785751359; x=1786356159; 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=tGGCN5AiLuhafhAM76uau+jsrwwMySs2OxzOgLlgNds=; b=N1G5qA+OiPUM4g6mPV4rNUKWpwOK9wmjRBByNmtaQMNorRXwx3itcwR1+AElfH2mCH LFAqUOTbavE0GDtUB635jVDea8fpAWUnfVJ0davlCYvcFVxUd256di3ykvV+KWpjkcPx pj+Nl2SgWUVOKEHNHJ1TKvleorcKcembZwP+8elap9EcUV9bdL9CVK/EKMxSsWJHUZn+ L/hEXHsbZLtUUCrZpFmSuVlXK/acS8Q52k141C9i4XhLW0ItQQA83l47nTyuJNGsOkcc 88DctfHsIJK9+moiht5y4EmqgbP/FUkF9OsVDEfa3dnWuZid4drd2ccpTiXqAxPCQszC jR0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785751359; x=1786356159; 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=tGGCN5AiLuhafhAM76uau+jsrwwMySs2OxzOgLlgNds=; b=oMaRB7A1GJf9BJUgbwKrNjQRjPvDIEiL9yvxpDylWQgv4UgTwTlys1kxUR7+ekjIkf m3IOBTeVOur803gmyEBTzPhkYupbWwHpWwl0yr6U3uM3gpyOLumW8K5ZE2wgKAIDH4m0 1T4XuFgsB3vajYosyqg4IbVQQ2dHetq7RNCOC1/bGxCIWfmjfE9otB1su902OH8xUFBq 2LDfnungrUmmWZkuHq86wmuO/tgGB0LClYYkdZOSdYf4eJftZzS8fb4At2ybNfjaGeuO fIG7uW/3eNccV3oJoUE0Xws0FsRQ+TylhzSSA9A6s7lRPW1DZRdzIYSz0aY3pzly55a+ x1JA== X-Forwarded-Encrypted: i=1; AHgh+Ron+jOglBsMLs2r1Nle0mLtXRV9tRc5p6Sf7DPGoZ+I1uzeDMQ4V+mRLaaUpnj3kgdSE5day4vuIcMdMa0=@vger.kernel.org X-Gm-Message-State: AOJu0Yy11kXhxZtngTV+H691FKW4fn7QWVaVWwqTPWcaVPIYj5klSX9z ulDOaN0i+qMOXyg/rrCfY6nikW9aAH7xbcltDNmq76S2TTsUM/kRtsWw X-Gm-Gg: AR+sD13ncnkaE76zKjLjAGnY9c8hsVyBhWpf3Q6zMC058VAvPNgTD2ZsoeJ7UtCMeDq HdtoSuwrW7KNm6xIrU5wSVUEJyFRZaoVhWdAjSTKfkg9sfJtJX0JyTT4IHrmxz1JBUibvyfZTZK bO/OjDSUyVZADT5V65DuDOiqXYbCZK6RVgf8mbmCjiNzlsP8n5ib2w+u4SjjVRMjWPeON/NJZqy wqzFOo0uW7rF73g7NY1Rf61UrBcigqvMb7sA/VyXUGPSDTuT5o3tlW5RAJyrIqQiR8nWLwGMUOD wHH5pHDj7P9vdnqj0yom7s2KY4ADQGyV/8/xn4rhlN/vuiqjlZgYDKLnyn7P+NVL9FlWKSZTvz1 4mAI9Tmf1UJUh0egwFBr5M2uAFXxQSNFuvJeXjbdoSZsZdRDWsNeymeoz8Bh4KEV7xd3VkMynDS q524N53nQ5Fm7V8kiOv0HRZMqXpFi7O1nA5WlOaYqpfy5oDGM2U9zzzN427fl4CJfaVOGnA2hWI q83i1DAwKYsl54= X-Received: by 2002:a17:902:da81:b0:2c9:e69f:8b0f with SMTP id d9443c01a7336-2d0521dd6e5mr100084465ad.17.1785751358276; Mon, 03 Aug 2026 03:02:38 -0700 (PDT) Received: from PC-2B0BA19500175.company.local ([210.184.73.204]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d04ae5ac3dsm35714945ad.23.2026.08.03.03.02.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Aug 2026 03:02:37 -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: Mon, 3 Aug 2026 18:02:27 +0800 Message-ID: <20260803100227.2585560-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 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" If (a), the per-task check is needed. Happy to discuss further.