From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) (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 CAB0C23BD05 for ; Wed, 5 Aug 2026 02:38:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785897538; cv=none; b=jgWhBulfvxH25UmJ63UzDfftklUj7cOgx8ndUrcUfyUqcI2YI40gcRoJDIw17wGfs8qrJjv0zJwloZgH6hFUHP7u0/Uxd2YySRUeGRoV7LgaCQTDMEuLGUMTjaMv5PjnKiMxA8T5culSzbIY9PX2oczPLKDYth2nk6jBa2Foi+I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785897538; c=relaxed/simple; bh=StWuNwMWcSLurBGxIEWsjCUhGxP6NJ1/FphOV0ONy5Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=CFswuCc/tv4KFFjqd2IQH+bq9SK8eHJo8qnb2HlUOGU0bahJ6ssRBOENtRY0JBvvXkrHJ2d+Ad0sZQxlrvKdpyWZ3ZXkMIcCK4NSoKjprQjBbbh8GLQccxHGhiUxM38Xll365CWI8BzaxUvPvCUBeFFjVvbyomdYiwBUwlS9EOA= 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=DDKtYjr/; arc=none smtp.client-ip=209.85.210.179 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="DDKtYjr/" Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-8487088510aso604469b3a.0 for ; Tue, 04 Aug 2026 19:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785897536; x=1786502336; 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=IO+OEX0pE5dfjGek39R3OTp89hH9hA1f3BnjiaMHBSY=; b=DDKtYjr/d1+haUKQvcySUvUkochGoONBHo3MvBMMZqN74hqNik8UjHRlVrKyvpszKJ TD00YuN2uZtlm75RecjxZd3UXxuLnDVvC7z4SgshZWlWxl+bLcEq0jMw+0CqVq1LXo4w 6AWqyS8P80nc5yLKZkpbE8QX+bZ6o0PQt/O487D3wp2gwhT7etBgXs8fHTzpNXjHZgOV svBdH7xkSobzt6+HdI8gh8myMF4rgsHYWkY5zGCG8MQ6N69UiVlASOzsks/u3Zh2gyEu QTsnm1++VEZxZWdTBkWLqiOzrPZVfjk3iAOeyzdqg8cx+j8Rd/TkF0pDKEfidJYOlquA fkvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785897536; x=1786502336; 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=IO+OEX0pE5dfjGek39R3OTp89hH9hA1f3BnjiaMHBSY=; b=noG/7IiBthdplAxB8hoR6f2o+hqS1pPrhNc0yQo1VNTIlaxhRlqwjB2xI4mT8GZsOz nQtipFBgWO7r9qsnWHaE21cnLq+PDtt3//TxhcW0SI2CBlSLQGiegIc1wjN8IYRRh0wz RU109BiC99e197GAflP3LdvicRtjXsbI1akWgOpw0ApTbIQ6wTpCmF7ZpEwJOGRd2Bin Dazucliq/NELQmvaQSN1rXCW97PMnUJS7d5b72bBKH//YsN8HSU7SfKGHoSoR51f0cJD IgPqMBwHefa6UEessbSYo3r7JL2IwspWry79SlY0f5hnNcKt9dSHTZjtm6Mlll6LMLz7 /MHg== X-Forwarded-Encrypted: i=1; AHgh+RqOUG7YYc0aeUFmaxxj2sCvoOigUu3EUmIdbKftQZYMbY8+UVU5A2C2kbaMdcAjjIl6g8Kx2oSNe07dCcI=@vger.kernel.org X-Gm-Message-State: AOJu0YwQSVkinNH5lLrj/yMsr4P7h4JXS1/Er206xfBXp87s734khrdz z27JM6EIvqW4y8CdBfjbwT5c5FXWdYG1KefBgSkjgitYHDvVbFk+H4Ho X-Gm-Gg: AR+sD11OXv20bv4dOUh4Zx8R3ZFb5Cfyg3IA37EcqAnSRjgaGWMxbf6r1+KH35Fp2OP 8XuV63pFThMYYuJ5scHBlA3eW+/X4F9uM/4wBS569yE4zdqp/kMGLfb/JieOSHelg116grOBDyD NH47AExz2ez61y/4PzH1/zknoMIPDXey4ItFaUJ0LAF/OqV+Sh5ccBLJvHrBOFjpBHIBolHp8Dy t4O9qFA0+jbOquYSqqerk/drDJoz7yD6+Q8K1axKvoO0MAFDrhzsE4J/wGaGrSEWcSa8qoXL9U5 uAuZZr3Ja8GLWOFjWAbMRbw5qHQhFRjWFRWF6UOvrmFO8y1D7Z9gFZAaRTSKZkwpG++fwQjyzcI zBk81BT1f4xnh26gIdbcApxO8CbaliDCgYEr/CSqzubmyXh+wDZ5tJhIsg61uLrteleEHyqb4JD Q+ebK//I0HPn7iZs3JpqaUZqfBv4rk6bMtm7jg295H2HKP6Lw6IPXgVIO1Tv2iHDi2fTSROD9zv kBd9JmxxZiW7A== X-Received: by 2002:a05:6a00:2d81:b0:848:6c9c:4074 with SMTP id d2e1a72fcca58-84f2dff6cd5mr3070828b3a.1.1785897535577; Tue, 04 Aug 2026 19:38:55 -0700 (PDT) Received: from PC-2B0BA19500175.company.local ([210.184.73.204]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84f2e52f84esm350981b3a.57.2026.08.04.19.38.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Aug 2026 19:38:55 -0700 (PDT) From: wanglu15 X-Google-Original-From: wanglu15 To: tim.c.chen@linux.intel.com Cc: yu.c.chen@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: Wed, 5 Aug 2026 10:38:45 +0800 Message-ID: <20260805023845.4040148-1-wanglu15@lixiang.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <2b23308912135b92e8f10e1b8909c89d8b46f41b.camel@linux.intel.com> References: <2b23308912135b92e8f10e1b8909c89d8b46f41b.camel@linux.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: Lu Wang Thanks, Tim. On Tue, 2026-08-04 at 12:42 -0700, Tim Chen wrote: > On Tue, 2026-08-04 at 23:07 +0800, Lu Wang wrote: > > Thanks, Chenyu. > > > > On Tue, 2026-08-04 at 16:17 +0800, Chen, Yu C wrote: > > > Yes. Besides, if I understand correctly, I suppose Lu Wang was > > > referring to the following scenario: > > > > > > src_rq has 2 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() found p2 and returns true for p2 > > > thus moves p2 out of its preferred LLC. > > > > That's exactly the scenario I had in mind. > > > > > Firstly, before ALB is triggered, the generic (passive) load balance is > > > triggered. It iterates over p1 and p2 on src_rq to see if it can move any > > > one of them to dst_rq, and in most cases it succeeds in moving p1 to > > > dst_cpu. As a result, ALB will not be triggered. > > > > My question is whether p1 is guaranteed to be moved out in passive > > LB. can_migrate_task()/migrate_degrades_llc() can reject p1 for > > several independent reasons — p1 pinned by cpus_ptr, p1 cache-hot > > with nr_balance_failed still below cache_nice_tries, or > > can_migrate_llc_task() returning something other than mig_forbid due > > to capacity constraints on dst_llc at that instant. If passive LB > > rejects p1 for any of these, ALB is still triggered with p1 and p2 > > both present on src_rq. > > > > Can we conclude that p1 and p2 never end up on src_rq together when > > ALB fires? Or would it help to set up a simple experiment and trace > > this path to see whether it actually occurs in practice? > > With 2 tasks on rq with different preference, active load balance could > pick the wrong task as can_migrate_task() checked in active load balance > will not consult migrate_degrades_llc(). How about the following patch > to fix this issue. > > [...] > > + if (env->migration_type == migrate_llc_task && > + env->src_rq->cfs.h_nr_runnable > 1) > + return true; > + > return false; > } Your approach is simpler than mine — it avoids threading migration_type across the CPU stopper boundary and doesn't need any new rq field. One thing I'd like to flag, IMO: this approach skips the ALB path entirely for migrate_llc_task whenever more than one task is runnable, deferring the fix to the next passive LB pass. So it trades "delay" for a simpler implementation. Wang