From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 25EEF2EA731 for ; Tue, 17 Feb 2026 21:45:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771364755; cv=none; b=L0j5d3gUbygiJn6rGcUY3qOIkpZ1fg7v03zT2guJE/T1FOIYiOWKqHRCqdF5yzwvMOOdklz3K0Ao8yE1hNE2xbU+YGzHr2ujtZpYV7hn9LAmCCLbpLs3UgUyOkl4uA9o/O48gwtX8f2uBSukGg0yHXVJ8ireM0Taeum7M7kMN94= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771364755; c=relaxed/simple; bh=lOHqMpzO184utk08yce8DpHypJZEGXY6rMZ1l68bYCM=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=diTuq6yTkarK01GtBYNVttHyV/Za6xmtNm1fqcLHUgks4tHQSR/oLO4o/1IPU84LN/bPbiFA/erCsVwPV3x0ZDPeYkwI0t8K6YPFNVekxXx4EavkjqlQZg+387CDzOnwoC/6Wi9Ftik8e2S0hLVuEPkPDY77kCP+26R6yHRT1ys= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=cTsuSL/Y; arc=none smtp.client-ip=198.175.65.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="cTsuSL/Y" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1771364755; x=1802900755; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=lOHqMpzO184utk08yce8DpHypJZEGXY6rMZ1l68bYCM=; b=cTsuSL/YFOkP+yTdq4ndmTMdzFzQKZ3p4Pd3+0l50vZPSBkTKoGGzd4n C6Rx6Znn0DFJaXcWhWpqQeob6gHCJSCdYD9P6jhklyF4gH2PwRWQPmNOt k0Cwe1RjAn8GEs8rjlNc1WmWv7xDOuxF5G2P92nvH07YAOrsnjMx/a82t cW1OQ8y5yoGvm5nWzMj24DIna2NNIyeD5J+aQAFtiBqNtdMU556Zpn1F3 upySGkK4Vsiid0WjnSaJKtx1w/f9PIK6yRmHBMRF0qrD9+lCJifhMM3Lt EHvHwEQxA0VzLn4Vn5PsECZT8ueGRk6ZAJ+SBBWSsn6G6FaHTR+CPM+Ur w==; X-CSE-ConnectionGUID: kInH65hUSt6fhPVqfQmoNw== X-CSE-MsgGUID: vvJfjvq5Qd+c19DR25Vdag== X-IronPort-AV: E=McAfee;i="6800,10657,11704"; a="76062076" X-IronPort-AV: E=Sophos;i="6.21,297,1763452800"; d="scan'208";a="76062076" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Feb 2026 13:45:54 -0800 X-CSE-ConnectionGUID: PKHwwAqIQ1u5r14gmZrr+g== X-CSE-MsgGUID: 836k+mMDTUOrlZpFxT36Iw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,297,1763452800"; d="scan'208";a="212173532" Received: from unknown (HELO [10.241.243.83]) ([10.241.243.83]) by fmviesa009-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Feb 2026 13:45:52 -0800 Message-ID: Subject: Re: [PATCH v3 11/21] sched/cache: Prioritize tasks preferring destination LLC during balancing From: Tim Chen To: Madadi Vineeth Reddy Cc: Peter Zijlstra , Ingo Molnar , K Prateek Nayak , "Gautham R . Shenoy" , Vincent Guittot , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Hillf Danton , Shrikanth Hegde , Jianyong Wu , Yangyu Chen , Tingyin Duan , Vern Hao , Vern Hao , Len Brown , Aubrey Li , Zhao Liu , Chen Yu , Chen Yu , Adam Li , Aaron Lu , Tim Chen , Josh Don , Gavin Guo , Qais Yousef , Libo Chen , linux-kernel@vger.kernel.org Date: Tue, 17 Feb 2026 13:45:51 -0800 In-Reply-To: <51bac0c9-863b-42cb-8c5c-7a6355840e19@linux.ibm.com> References: <4754991218da7da039a0891b0b9647f6eabd5716.1770760558.git.tim.c.chen@linux.intel.com> <51bac0c9-863b-42cb-8c5c-7a6355840e19@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.1 (3.58.1-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Wed, 2026-02-18 at 00:03 +0530, Madadi Vineeth Reddy wrote: > On 11/02/26 03:48, Tim Chen wrote: > > During LLC load balancing, first check for tasks that prefer the > > destination LLC and balance them to it before others. > >=20 > > Mark source sched groups containing tasks preferring non local LLCs > > with the group_llc_balance flag. This ensures the load balancer later > > pulls or pushes these tasks toward their preferred LLCs. > >=20 > > The load balancer selects the busiest sched_group and migrates tasks > > to less busy groups to distribute load across CPUs. > >=20 > > With cache-aware scheduling enabled, the busiest sched_group is > > the one with most tasks preferring the destination LLC. If > > the group has the llc_balance flag set, cache aware load balancing is > > triggered. > >=20 > > Introduce the helper function update_llc_busiest() to identify the > > sched_group with the most tasks preferring the destination LLC. > >=20 > > Suggested-by: K Prateek Nayak > > Co-developed-by: Chen Yu > > Signed-off-by: Chen Yu > > Signed-off-by: Tim Chen > > --- > >=20 > > Notes: > > v2->v3: > > Consider sd->nr_balance_failed when deciding whether > > LLC load balance should be used. > > (Peter Zijlstra) > >=20 > > kernel/sched/fair.c | 77 ++++++++++++++++++++++++++++++++++++++++++++- > > 1 file changed, 76 insertions(+), 1 deletion(-) > >=20 > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index b0cf4424d198..43dcf2827298 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -9649,6 +9649,11 @@ enum group_type { > > * from balancing the load across the system. > > */ > > group_imbalanced, > > + /* > > + * There are tasks running on non-preferred LLC, possible to move > > + * them to their preferred LLC without creating too much imbalance. > > + */ > > + group_llc_balance, > > /* > > * The CPU is overloaded and can't provide expected CPU cycles to all > > * tasks. > > @@ -10561,6 +10566,7 @@ struct sg_lb_stats { > > enum group_type group_type; > > unsigned int group_asym_packing; /* Tasks should be moved to preferre= d CPU */ > > unsigned int group_smt_balance; /* Task on busy SMT be moved */ > > + unsigned int group_llc_balance; /* Tasks should be moved to preferre= d LLC */ > > unsigned long group_misfit_task_load; /* A CPU has a task too big for= its capacity */ > > #ifdef CONFIG_NUMA_BALANCING > > unsigned int nr_numa_running; > > @@ -10819,6 +10825,9 @@ group_type group_classify(unsigned int imbalanc= e_pct, > > if (group_is_overloaded(imbalance_pct, sgs)) > > return group_overloaded; > > =20 > > + if (sgs->group_llc_balance) > > + return group_llc_balance; > > + >=20 > group_llc_balance is placed before group_imbalanced. In cases where a gro= up is both imbalanced and > contains tasks preferring the destination LLC, LLC balancing will be sele= cted first. >=20 > I assume the reasoning is that migrating tasks toward their preferred LLC= may also help reduce > imbalance, and in cases where the goals conflict, the nr_balance_failed /= cache_nice_tries > logic will eventually fall back to regular load balancing. Is that the in= tended policy? >=20 > It might be helpful to briefly mention this reasoning in the changelog, s= ince this ordering > changes balancing priority. >=20 group_llc_balance naturally aggregate tasks to LLC and could create imbalan= ce between LLC domains.=20 If we do group_imbalanced first, then after we balanced the load=C2=A0 and move on to consider group_llc_balance, group_llc_balance will cause load imbalance between the LLCs again and undo all the previous load balance work. It is better to do group_llc_balance to move the tasks to their preferred LLC first, then let group_imbalanced do adjustments to imbalance in load. The can_migrate_llc_task() check will prevent group_imbalanced from undoing the work done previously in group_llc_balance. Yes, we'll add some comments to explain the reasoning of load balance prior= ity. Tim =20 =20