From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.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 C792B3FFF82 for ; Mon, 27 Jul 2026 12:39:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785155981; cv=none; b=fxo+kaRhsvK3CJJzyygkWEWaVAVAsjGh2QEqos+f1DTl7Mxn9lYlH8Zz0AkNhHSXPOlsfCw7xjiUles54hMaq6VRqsqlNVK/arrKfICjaoaWkpJQuPT74PPUsfquisK4lge3olH8WlrGK0M6txlMBlx/tNDx2tprikVXj4MNbFw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785155981; c=relaxed/simple; bh=E/wGOmfI12DWdkgcLhn47ZcNkaa/E1B7QDQOpiQiPc0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FSHpt/yoJ6Fv9JgfrqY/SYzSqLT7z/UJ7W2etoLLxEBJH1acSu6Zn0ty1KHkuPDBNZRK5AsYfbPb0J5hMkVwnocWfwnQHLc+AmZZS+MW/jhM0FmdaElGIdwFzY3wjPvIu7Bv6GFVdkxaacBhC5oATcDEvq8x62+NiJ04HQ5UUMQ= 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=oM7nU0Ma; arc=none smtp.client-ip=209.85.219.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="oM7nU0Ma" Received: by mail-qv1-f42.google.com with SMTP id 6a1803df08f44-8eeb4508f29so23780966d6.0 for ; Mon, 27 Jul 2026 05:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785155978; x=1785760778; 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=ZIQ7HcMD3HZYWvpV7I24fp3PFeY1xwbDGuBRQW8md3M=; b=oM7nU0MaOddiewA87pDlSYN/7Dd2+pXLxkiRUgmejxxwEFGqaxJUrzNrnfCN8r2ZVR lmIWd5Dkq/llMZHGl0WvZ2kKelxH7weiM/p9r2Wjfbi/6VE9+dbHAMW4dT3qwzDIuGVS M047fbUfdADnVUNVyJIIMJXmAcZ7tc7PYIhV4kaSAOrwF29WMbBNmDBCgyKGs5SFNaX2 PEyohqOmLrG6on0gekYOm7/5Iot4YrMWX1UIPai/cRdRc2FhZnRGeY0hOnxVQgWhobC1 NBFQs3qdxw7zDzYsDGBjZ3v9BbbKbRWiwwqmec4xsrbNlVPYQbyeVaG4MScA0egoiq3Y 0zEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785155978; x=1785760778; 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=ZIQ7HcMD3HZYWvpV7I24fp3PFeY1xwbDGuBRQW8md3M=; b=LcWy+dofjL8yNiW5232fv5peRcy2E/Mqx9MhutrCmusvwQg/DARtoqm3TcFsd/hXI3 dCVjaFrQQhUeSobfMFSv+kJhXTaqBz6bMtIOz9PdlIGfxsth5IQb4TRwybpY7xEC+V1N jKATnIuhU7pUbe5WvdCJYhbvpG8t6HwR6wYUPOu7/UkV3Cfu/24iMFzRMO+1loead6Li WS56di+KvgnOrmdcw8BDbO4kPBg9pR6Z/ztyjnYxzI5qGpVuganl1OzhsgLDNp9UaKAF mLhrx3ZKT1YmfmJxE6aOugBMdpTmzaWwULEXt0FhgKCGFa5uLzZ7Bg8tRciFmp54OjVa xbCw== X-Forwarded-Encrypted: i=1; AHgh+RqbTwfJjYdYpOqh+QpiLi5xIoEY0JL186AEMM3hrkDwqlsJSHnnKtZnri8ZAHvHLOOt/WaXicncFNmBseQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxBzCHj7G4hLUxKTAGk7Kpjx6rBTxYXX3EAUOXhMbtuEdPGhIIN dcmHHJLKDwgcvWAZjd9E2sAJuUb8RpVqNrxXi7U+sPgv7AMtRbvD1Ov/ X-Gm-Gg: AR+sD13Gmh4iA/Ie88BThynt/HLkq/eoQI5MuvRMycaetyUp0SUkzWFd+lSSyk3vLtN uEAmvR+rEh0c29GyAZ3K0DoF26kWqRKsoTMTQFFpgbBf4GjkieFZtQqia7y2Ov3oIDNYbomMU4y rBRCmGFWS+60df//5LgaFgWUj0nVs9/MEsvSxCnU3glkK2skYZm/+PmZQnMLmpAI08U0HMX30uW S0wccDoLvdDDXHtpUycgOqgNOLxPDXKlyX+hLnxBKOCRHK5gSznlI25XRo6wws3QNSDKmw6uUQG ic7xXioO6lUHZ/VyreNLIt8hv3TD76rwzn9n2dDp/P4dt80JRKqXOAu5zTKHgAm1CTr3lxY30dw 8ltNao49jDxBJsfBneczazbr5F1C9irvC83FyfquLhgoz143nLysXUhfR1riSfw1n4qFg50cKB0 q+WXFCWznjBTHlFg== X-Received: by 2002:a05:6214:767:b0:8eb:70e0:47d0 with SMTP id 6a1803df08f44-907ec8034f2mr90474056d6.37.1785155978504; Mon, 27 Jul 2026 05:39:38 -0700 (PDT) Received: from osman.mioffice.cn ([43.224.245.178]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-907e858195csm63677906d6.21.2026.07.27.05.39.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Jul 2026 05:39:37 -0700 (PDT) From: Zhan Xusheng X-Google-Original-From: Zhan Xusheng To: yu.c.chen@intel.com Cc: kprateek.nayak@amd.com, mingo@redhat.com, juri.lelli@redhat.com, tim.c.chen@linux.intel.com, vschneid@redhat.com, mgorman@suse.de, rostedt@goodmis.org, dietmar.eggemann@arm.com, bsegall@google.com, yi1.lai@intel.com, linux-kernel@vger.kernel.org, zhanxusheng@xiaomi.com, peterz@infradead.org, vincent.guittot@linaro.org, chen.yu@linux.dev, Zhan Xusheng Subject: Re: [PATCH] sched/cache: Fix a thread aggregation conflict when there is one runnable task Date: Mon, 27 Jul 2026 20:39:25 +0800 Message-ID: <20260727121730.2148901-1-zhanxusheng1024@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <70eb8310-bc01-4598-99e5-c53bf101a36d@intel.com> References: <20260727064111.1350672-1-zhanxusheng1024@gmail.com> <70eb8310-bc01-4598-99e5-c53bf101a36d@intel.com> 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 From: Zhan Xusheng On 7/27/2026 5:46 PM, Chen, Yu C wrote: > I did a further investigation, and another reason it holds: with only one > running task, migrate_degrades_llc() is not what keeps the task in its > preferred LLC. In the regular load balance path can_migrate_task() already > bails at task_on_cpu() - since that task is curr. And in the active balance > path alb_break_llc() blocks it first: > > if (env->src_rq->nr_running <= 1) > return true; > > so the task is not pulled back either way. Thanks, that all makes sense. I traced both guards and they hold: - Regular load balance: for the single running task can_migrate_task() returns 0 at the task_on_cpu() check, so it is never pulled back on the normal path (and for a non-running task the migrate_degrades_llc() -> can_migrate_llc_task() == mig_forbid check catches it). - Active balance: need_active_balance() -> alb_break_llc() returns true because nr_pref_llc_running == h_nr_runnable and src_rq->nr_running <= 1. What convinced me it is not symmetric - i.e. that the forward migrate_llc_task still works - is that in the forward direction the task does not prefer the source LLC, so nr_pref_llc_running == 0 there and alb_break_llc() returns false. > Good point. OK, let me add description in changelog: > The adjacent SD_ASYM_CPUCAPACITY filter was left unchanged. In theory > it should have been handled in the same way, but it is not clear yet > whether any platform has both multiple LLCs and asymmetric CPU capacity, > so the asymmetric CPU capacity logic was not fine-tuned here and can be > revisited once such a platform shows up. That wording answers my question well - thanks for spelling out that leaving the capacity filter alone is intentional pending a multi-LLC + asym-capacity platform. Reviewed-by: Zhan Xusheng Thanks, Xusheng