From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) (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 81A1D3C6A5C for ; Fri, 7 Aug 2026 09:58:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786096717; cv=none; b=a6FKQDcFcAuV4PueEK/Leh7i3EZ0+fqE1ETMLSuQRY32eyvaLi1B58mqTKA2qYDYPadX/ZeonGie1hBGjUww7WFIBKFSsHfgAH60PXnCjTIxni/BZSNeQNHL1fhPnNJdR/2dbFSlZ2ooqWWNRWIDNKVUKqawGwr37S+Bxx0p4Qs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786096717; c=relaxed/simple; bh=/+L1wzt3BtQXQ+J+YEPCltQvQf/iL5wVdAIIdRvhKLQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mm+oZFRyHiVNwGjJDoxhrkgWytNjnjWMnQgtrIkzbsJ9aAhljw0/dlnIdtPPBfxDSWxpCdg6xCyQ5qJH4NKmq1UwSiBc4lFGYUeleCxmNJojntcZOLr5L7ClAgRP/7gEs2fZle63T72cIlzZAlOb+nzSLt1vZHZ0/rvQN+HSMVs= 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=n5HrwSOQ; arc=none smtp.client-ip=209.85.214.180 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="n5HrwSOQ" Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-2cee9b74ee1so27537045ad.3 for ; Fri, 07 Aug 2026 02:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786096716; x=1786701516; darn=vger.kernel.org; h=content-transfer-encoding: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=59jxD7b6QXojTKyX7cwwz6TkYuxAYZpz55Nz9gERZjs=; b=n5HrwSOQLmtqr592dQsXfPfqw6g6zVkqy1JE21em56O7kVd2yoyBde+1am+LJvlb+o Tfe5IfwyCeWgVkolsdv/njULY6gkQ4PPlE/ySqK80V3SwaVy4CYEqZztR6ghi9AxNvg+ RW8rD862F0LXmj/T3zO3NdNKpdkzChlhfE+P+r9zbTViXUzT6JG/Ra7xQYOizujMon6+ T3pYHLtmS5sdrY3azcFWc1pqZ5NBCXGHWR0L7nmjSXU6LJLjkcyJxpw5vn8sKz2zAsjP YJu0oKRFexFFU7K0Nc5gOHUjCjWrxvXNdRZfpKnLEboEB8IUAsoGmpVvY55SUHH/58vj aUYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786096716; x=1786701516; h=content-transfer-encoding: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=59jxD7b6QXojTKyX7cwwz6TkYuxAYZpz55Nz9gERZjs=; b=XmI3PVSpw5Sr39sKxJb1+YyQhlpPw9sdDluy4HixaW4ZB7mZebNv4O6EwAi8vw7TUj oYJg9x9VkYT57GjuluPSw0qBt/4R89NbwKY+AxVMb2HTmBUWQwbC36EubGAxE+hOOJhT dg0bOquGwFO9VuJ/mZxO4XrV1yty9XhSRrtx/gzIZxV212aqWFaw2jjTameQiqS/ua+1 SoiulVyY/lJBJ11qincYLIZMGzk3Mc9nqPt223EgJ5LzEJG9TO0ecN4XxVSwrYfq51qK C+NHQdFzDK73ibpyV+bAu0aBwYSyr5K3wVOykVJ2slOhyVsUke/P5zM0ePWmoXJu+CGN 4YRQ== X-Forwarded-Encrypted: i=1; AHgh+Rr1AFAdBKpvaB98FVUAM6is3LFCr2lUivrZhCiBlQDUD3UPYoIw6cZ2G4VqOeqqo7CUd4fRm3TbYxQ9p6M=@vger.kernel.org X-Gm-Message-State: AOJu0YxcJosZDdCPPZuTw9RVzHG3areUz+tXC6Br79AcJ2XCrgXEnXKV xiSE/FbUBlaZrz2xjUC/9DtMxv3Ia8jbeq2Uw4IKw4GGaxKwESCB508u X-Gm-Gg: AR+sD117jMCdHWSAVlX5oqJD/zhLPmOnLMGEvjMYU7E/pC7+62mfIrlmfIp+FcFvDJ1 dwDdFMkATaM/yGezLTNK6vALwOg5XCCJA/27zOf4TP4nZ0qMaZXDcJ83F38QZUtzA5n4VNrPuS+ bQegkYLNpfd0CIaYRCCuo/Dp+yvZHmjgulND3ZjTOMvi5MUVJN7xR5SuI7SdZ2aIcYRe6ZNWB1H 8PIfjqlgGbtmW3vBfvfKXQbOB5ZK+N9wvGfUSDz71R0X/RCNJ5AbXBrrHQ9icAw0ilInMYHCK9A cqIzaJ8ZpNuUHuS4JtxkDzufGWE+2gQqSgQOUOJ79uQSR5q4rFFMZ8LI2dWTUI7+/dj2UH35DBu +wlDfHYfHdr7fDxO4iRtV7TQra9hpMUQDG7DnhEIwXE8M3aozk3y4DSvd3EF7gc/FgJqUaw2VK9 S/ILXg9BQ+WmSozTlo5ZQGY2Ggk4ngnK3TnuZgDENupmj0kN4XFkd5mynqxS3Chbn6W7RxhRWge FmylTNkPUJwT50= X-Received: by 2002:a17:90b:1843:b0:37f:bfa2:1887 with SMTP id 98e67ed59e1d1-3903c53639amr23469257a91.8.1786096715730; Fri, 07 Aug 2026 02:58:35 -0700 (PDT) Received: from PC-2B0BA19500175.company.local ([210.184.73.204]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3925ff244aasm1918019a91.12.2026.08.07.02.58.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Aug 2026 02:58:35 -0700 (PDT) From: Lu Wang To: yu.c.chen@intel.com, Tim Chen Cc: 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: Fri, 7 Aug 2026 17:58:25 +0800 Message-ID: <20260807095825.1595970-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-Transfer-Encoding: 8bit Thanks, both. On Fri, 2026-08-07 at 14:48 +0800, Chen, Yu C wrote: > On 8/7/2026 1:22 AM, Tim Chen wrote: > > On Thu, 2026-08-06 at 23:35 +0800, Chen, Yu C wrote: > > > It looks like this proposal provides fine-grain control on per-task base > > > migration strategy is promising. > > > > > > If we overwrite migration_type for ALB (default is 0, i.e. migrate_load), > > > then in can_migrate_task() a delayed task might not be migrated in ALB: > > > > > > if ((p->se.sched_delayed) && (env->migration_type != migrate_load)) > > > return 0; > > > > > > So an enhanced approach I'm thinking of is to pass > > > migrate_llc_task information via env->flags: > > > > > > #define LBF_ACTIVE_LB_LLC 0x40 > > > > > > static int active_load_balance_cpu_stop(void *data) > > > { > > > return __active_load_balance_cpu_stop(data, 0); > > > } > > > > > > static int active_load_balance_llc_cpu_stop(void *data) > > > { > > > return __active_load_balance_cpu_stop(data, LBF_ACTIVE_LB_LLC); > > > } > > > > This is a good catch. > > > > It may be easier to create a migrate_llc_task_alb type and pass that > > in migration type. Then modify the above as > > > > if ((p->se.sched_delayed) && env->migration_type != migrate_load > > && env->migration_type != migrate_llc_task_alb) > > return 0 > > We still need a channel to carry migrate_llc_task/migrate_llc_task_alb > into the alb, since the stopper builds a fresh lb_env - hence > rq->active_balance_type was introduced in Lu Wang's proposal. We can > reuse the callback slot in active_balance_work instead, pick > active_load_balance_llc_cpu_stop() at kick time, thus no new rq field > is needed. Good catch. I agree that overwriting migration_type in the stopper changes the existing delayed-dequeue behavior. Picking the callback at kick time and dropping the rq field looks like the cleanest version of this so far -- it fixes the original issue I raised without affecting delayed-dequeue behavior. I agree with refactoring the patch along this idea and send patchV3. Lu Wang