From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) (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 B211C3B7763 for ; Tue, 11 Aug 2026 16:10:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786464647; cv=none; b=a0ddNNHS8EufXu2KwAAznWtO/7mqTRwrGk7GRa+yr8TyEWvE4yUioPYxMqCfA2GQQphhfwIJsh3hsCAPAg0v8RJ+MBAPkweqk9wQ9PzihxPPV6iJi1xHPM6lgCLfuvYicE0vv/5Y8WxFAeTIfQ0BzJYH3WF/dS6s567eCAmvSTU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786464647; c=relaxed/simple; bh=pt0Kw/CER6RLIhy41IBLLy9IOei/V1ItXhNyPzCuFJs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZGrlz0+8KBhbZF+UsfyIJSM2NBI4cGwSkeInJXCRR1MhtAh1HDtjv4Wanr47co7tcUYOCtXhG5JxzshLXem7DnYir6dUoqB5xF6coPLNV9XkDMZMIeryXCk5sI5+kOlbwuh/QJCgQtfoe0FjtHLZ0fL4q2hLe/RSUQ079uJ6Mlg= 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=GvIrUoUo; arc=none smtp.client-ip=209.85.214.171 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="GvIrUoUo" Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-2cacb8416a1so1482445ad.1 for ; Tue, 11 Aug 2026 09:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786464645; x=1787069445; 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=ir7x4shBjMUANBfKRWaiVpfUIlDqGnoon3uXdO+QF3E=; b=GvIrUoUo0PYcTJHQ3S7HP7fRRsmY3riAdHWxxbtZxJGgmWdChQ92Vh/DW6NLf2vHI1 SBDmTuZuHniI0nWqn198hSQElsiGzeehgAQylUrCnUtyVIfxJIAhIKp9g5V9NmhDPmjM KGmuUpVTu66zxc6DE8XP90u+r8jFBQ9bgIRjVyQVSFVm5zuwDWSvem2umBCPkUwxKHK7 /we+6yKcT9WcfdFUFqPUV8A/fksEQo7D4+QdDs7ZUikjbCKkBjZhGrJGNCp4j+tWB15s A4Em1jur8uwXtyzW3oBJotjpxH8ZY284XgvMFq6Yu771+jgV8xJbTQCJZs0gHl1VcuA0 SqTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786464645; x=1787069445; 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=ir7x4shBjMUANBfKRWaiVpfUIlDqGnoon3uXdO+QF3E=; b=Jwhl3X6BKqKOJXDZ6Kj34oZ+D5QQUWdxK8/btMY1IrQDw26BbsZ8aE3dofC8YEAtKx MwtaJDN5OskBJmdiEMJqvyqwjwMEBTEKPqQOyzBIRqjvTAXXHwCg39yH2f19k8W2cQr3 X62ovivUgynMdJFmBhqsQ+nzmBEGhqq6ihzf3PHxGGYpHr+ki86vvB+RU8Dwi9I0seWH dhuTJhmIISBjXtz2ZRPVBIxc0HCpZpFZgjNFhGvnpbMRawdBAKT6n78FLKkDyvGi1+EA axQx11kQR5Mf5tFmlbMVnNqcsOKIdOxAIGnVtUjnI0ACVL/G/X8vo9sheUZmBzCtLaof cU2A== X-Forwarded-Encrypted: i=1; AHgh+RoZqxovAbYWryHL0dGaxV/1nz1ZxrVoHL1npTyJ3SyBswRj5ju920HKpyymGnVwpWkF1DAViMeKI1JCwQs=@vger.kernel.org X-Gm-Message-State: AOJu0YzOs/V39Cnspyl1cy53En0pu5lgp6GqRmOVPVZ9bqZSHUOWFF6+ jMWKL33q/X8+2TfTcFGY2SiFvu4fkFrUn37v3GNdeAiJ8ys0yiZQ3CPrwQM1JQ== X-Gm-Gg: AR+sD10f8Cz/KGEuqluq8nYDnQq5BJL5nWjAuVvmkgPtpBwaTlpfOGDjqp+dwTjXpZN wJxERuseY6dy+hlsTa61k+VaBS0awWXHBUhVq2riXgLYrrbBekQgPLUdmmLgN3QzmAL2MLi+8go /ucur7iUKnxIsGwhYfjk+OaWcdRdFuSnNQew+vRDhpQI6JgBtuNhucA3icZsmNAjsicxAzG9WJt YwCNlc34JjzWMRDGrzvqesckx/xeG4636TEpEPjlU8qFC9e7eMsTKVbL7XUZNHGk8siJpot/obN t14go1wcQ1NMne9Uji172R4KjiigBJakPHUmcCFJubGVzHepQgmzWmM4mVxVSDFIM7tQnmwiD8s aXcmPsXEhS3UAc5FAB3PrklZI1QCxptAk1Ds0JZ5rD0jnhEQ1My0mRdk7/T13l9NKKP0rsf3zAG qkeoquWs365Sjiv8RTPFwxqaGcyy+bQ5e6arKOdH17r4Y7+mmIp+LC+GF+mP00KsldiuZsoohpc YbBqYTzmtlMCCY= X-Received: by 2002:a17:903:2a83:b0:2c9:c952:6e9 with SMTP id d9443c01a7336-2d317785d98mr56083925ad.2.1786464644714; Tue, 11 Aug 2026 09:10:44 -0700 (PDT) Received: from PC-2B0BA19500175.company.local ([210.184.73.204]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d315f44eefsm10755605ad.31.2026.08.11.09.10.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Aug 2026 09:10:43 -0700 (PDT) From: Lu Wang To: yu.c.chen@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, tim.c.chen@linux.intel.com, vincent.guittot@linaro.org, vschneid@redhat.com, wanglu.priv@gmail.com Subject: Re: [PATCH v2] sched/cache: honor migrate_llc_task semantics in active load balance Date: Wed, 12 Aug 2026 00:10:33 +0800 Message-ID: <20260811161033.524123-1-wanglu.priv@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <14f72439-d8f4-47aa-b3ce-6b8485ae46ea@intel.com> References: <14f72439-d8f4-47aa-b3ce-6b8485ae46ea@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Chenyu, Thanks for the review and the suggestions. On 8/11/2026 6:23 PM, Chen, Yu C wrote: > On 8/9/2026 6:53 PM, Lu Wang wrote: >> A passive load-balance pass marks group_llc_balance as migrate_llc_task >> and queues active balance when it cannot move a task. The CPU stopper >> callback constructs a fresh lb_env, so select the stopper callback when >> queueing active balance to preserve the migration semantics across the >> asynchronous boundary. >> > Worthy adding a [Problem Statement] section to describe what issue this > patch tries to fix > (with polish): > src_rq has two 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() finds p2 and returns true for it, thus moving p2 > out of its preferred LLC. > >> Changes in v2: >> - Select the stopper callback at kick time to preserve >> migrate_llc_task semantics in active load balance without passing >> migration_type across the stopper, which affects delayed-dequeue tasks. > Maybe move the above reasoning about why the new stopper function is needed > into the commit log for future reference. Thanks. I will add the p1/p2 problem statement and move the rationale for selecting the stopper callback at kick time into the commit log. >> +/* >> + * Returns true if p's preferred LLC does not match the destination CPU >> + * under migrate_llc_task semantics. Passive LB passes migrate_llc_task >> + * in migration_type, while active LB carries it in LBF_ACTIVE_LB_LLC. > "while active LB carries LBF_ACTIVE_LB_LLC in env->flags to avoid > overwriting env->migrate_type." Thanks. I will update the helper comment accordingly. I will include these commit-log and comment-only updates in v3. Thanks, Lu Wang