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 40C1C342528 for ; Mon, 15 Dec 2025 19:32:47 +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=1765827171; cv=none; b=nBSMDtuk4rnF7w6saYdBANlMvylVweG4aaHv+2CHUEmDptcvHToG7tVzKp6K16fJMreej5ZkMH0KxIbK+KMXevTFNwvu6mijz7Hv4KhvQ/p78a+pIa67Dx/TLGwWZaD0SlZwo0aUooGIRHAg9QNeNIO8sKCidNikazcqFiXLwXY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765827171; c=relaxed/simple; bh=Pl5ylbB07tmlR8GexYjpb0FbbXzervusi0hLWcYVQO8=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=bwGl4Ujq4PNpbJ7LLA+8HuYhTZ7ZHSh9KYyPfVsJ3SngoDlLJ5HeiqgYgzB5mP7I+QNPsuXsj5fSzri4z59Dfyk84gJihQJbxmOjVu6Hm6ktZU3u9hJwi+vAGOpxWV3MzyE6shjqFV2SZKNp26Uj6kkdCxBQ5ZUnSHl6eCEYX5M= 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=H1a7njhQ; 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="H1a7njhQ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1765827170; x=1797363170; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=Pl5ylbB07tmlR8GexYjpb0FbbXzervusi0hLWcYVQO8=; b=H1a7njhQJUJpea0tNUblfuZ6mG2aKnXxfjj/lHExb1ZxS8j9zTnDU4m2 jz/NdUKgSAF2fAckcxULkmyM/5dOAT3NhJYM9YS+pyN+xSAHkrQUcRPLX 2Q5JniNULVvEZY1V7ylghIBy/2Ycsm/bleU9drxMqT065c0rFP9o9qOYT mYEcdAl5LJKwATYgXk023bJ0SjEgeiiTn+15Rwe/mGcJZ9Jvs4Hx48+tY JK0GVwhHuv4f4hw6pgCuYNIuTVzXZ9g0xOavEqxGHuqbig5Vyxi0ZedZs PCz34hi8hnvFz7+zrmrT0BHC/FeViVRFcNtL05JeraZcPg0wIU+ExxZcp Q==; X-CSE-ConnectionGUID: hts/1yo7Q9Cm6nv74OD/cA== X-CSE-MsgGUID: SGfekyWSSkG5m5cpg3P5bA== X-IronPort-AV: E=McAfee;i="6800,10657,11643"; a="71372514" X-IronPort-AV: E=Sophos;i="6.21,151,1763452800"; d="scan'208";a="71372514" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Dec 2025 11:32:47 -0800 X-CSE-ConnectionGUID: eY88RNytQc2AGMrJqDcRDw== X-CSE-MsgGUID: 4vGS06twTuWVnsLIloip6A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,151,1763452800"; d="scan'208";a="228462602" Received: from schen9-mobl4.amr.corp.intel.com (HELO [10.125.110.163]) ([10.125.110.163]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Dec 2025 11:32:45 -0800 Message-ID: Subject: Re: [PATCH v2 05/23] sched/cache: Assign preferred LLC ID to processes From: Tim Chen To: Vern Hao , Peter Zijlstra , Ingo Molnar , K Prateek Nayak , "Gautham R . Shenoy" , Vincent Guittot Cc: Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Madadi Vineeth Reddy , Hillf Danton , Shrikanth Hegde , Jianyong Wu , Yangyu Chen , Tingyin Duan , Vern Hao , Len Brown , Aubrey Li , Zhao Liu , Chen Yu , Chen Yu , Adam Li , Aaron Lu , Tim Chen , linux-kernel@vger.kernel.org Date: Mon, 15 Dec 2025 11:32:44 -0800 In-Reply-To: References: 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 Fri, 2025-12-12 at 11:34 +0800, Vern Hao wrote: > On 2025/12/4 07:07, Tim Chen wrote: > > With cache-aware scheduling enabled, each task is assigned a > > preferred LLC ID. This allows quick identification of the LLC domain > > where the task prefers to run, similar to numa_preferred_nid in > > NUMA balancing. > >=20 > > Signed-off-by: Tim Chen > > --- > >=20 > > Notes: > > v1->v2: Align preferred LLC with NUMA balancing's preferred node. > >=20 > > include/linux/sched.h | 1 + > > init/init_task.c | 3 +++ > > kernel/sched/fair.c | 18 ++++++++++++++++++ > > 3 files changed, 22 insertions(+) > >=20 > > diff --git a/include/linux/sched.h b/include/linux/sched.h > > index 278b529c91df..1ad46220cd04 100644 > > --- a/include/linux/sched.h > > +++ b/include/linux/sched.h > > @@ -1408,6 +1408,7 @@ struct task_struct { > > =20 > > #ifdef CONFIG_SCHED_CACHE > > struct callback_head cache_work; > > + int preferred_llc; > > #endif > > =20 > > #ifdef CONFIG_RSEQ > > diff --git a/init/init_task.c b/init/init_task.c > > index a55e2189206f..44bae72b5b7d 100644 > > --- a/init/init_task.c > > +++ b/init/init_task.c > > @@ -191,6 +191,9 @@ struct task_struct init_task __aligned(L1_CACHE_BYT= ES) =3D { > > .numa_group =3D NULL, > > .numa_faults =3D NULL, > > #endif > > +#ifdef CONFIG_SCHED_CACHE > > + .preferred_llc =3D -1, > > +#endif > > #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS) > > .kasan_depth =3D 1, > > #endif > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 0a3918269906..10cec83f65d5 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -1300,6 +1300,7 @@ void account_mm_sched(struct rq *rq, struct task_= struct *p, s64 delta_exec) > > struct mm_struct *mm =3D p->mm; > > struct mm_sched *pcpu_sched; > > unsigned long epoch; > > + int mm_sched_llc =3D -1; > > =20 > > if (!sched_cache_enabled()) > > return; > > @@ -1330,6 +1331,23 @@ void account_mm_sched(struct rq *rq, struct task= _struct *p, s64 delta_exec) > > if (mm->mm_sched_cpu !=3D -1) > > mm->mm_sched_cpu =3D -1; > > } > > + > > + if (mm->mm_sched_cpu !=3D -1) { > > + mm_sched_llc =3D llc_id(mm->mm_sched_cpu); > > + > > +#ifdef CONFIG_NUMA_BALANCING > > + /* > > + * Don't assign preferred LLC if it > > + * conflicts with NUMA balancing. > > + */ > > + if (p->numa_preferred_nid >=3D 0 && >=20 > I wonder if the restriction here shouldn't be so strict. In Mel Gorman's= =20 > patch (e496132ebedd sched/fair: Adjust the allowed NUMA imbalance when= =20 > SD_NUMA spans multiple LLCs), the value of the 'imb_numa_nr' is checked= =20 > to determine if |SD_NUMA| imbalance is allowed. Could we use this same= =20 > check to decide whether or not to perform a cross-numa migration? If we set the preferred LLC that's in a different node other than the prefe= rred node, the preferred LLC is going to fight with NUMA balancing and bounce tasks back and forth between nodes. NUMA locality is going to affect perfor= mance more so we'll let NUMA preference take precedence. Tim=20 >=20 > > + cpu_to_node(mm->mm_sched_cpu) !=3D p->numa_preferred_nid) > > + mm_sched_llc =3D -1; > > +#endif > > + } > > + > > + if (p->preferred_llc !=3D mm_sched_llc) > > + p->preferred_llc =3D mm_sched_llc; > > } > > =20 > > static void task_tick_cache(struct rq *rq, struct task_struct *p)