From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (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 AB5BD33F387 for ; Tue, 16 Dec 2025 22:30:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765924209; cv=none; b=IhJFbvMP+BDlPpWlHHFM9YPOV1iDHIk/TwUBq5YFJSPDO3iORDgXaaBESIhLf4/JstkS/32TJXEJG14okBFAN7OaACQLZwYv9W+rj3CMk1FOqaQ51ssP564WrymPOuqNEUTqJbAF8eaPTTx4W5rUvOn9I57FuW81Xib3f2bow98= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765924209; c=relaxed/simple; bh=hHSX0hohRrlTX/MmckOgHs8gbau3qB7M/IquJtcvWa4=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=taJwyiIn+TCA+hdhbNF0fLX+0+OCjeiW8FtdC+XFa/brgXbQtwO4BjG4HaVY3RDfLaDS6Fl8v8qoWCHGvJQ8+JzmAohSpjlY9t4J3zkGiE2/NOkWlqrKkNBKHA2xgLq8RgURynLBHDiwDIAA1kdR12T15UbLpLNEYVFG19be0AQ= 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=ZnMGEIyf; arc=none smtp.client-ip=192.198.163.19 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="ZnMGEIyf" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1765924207; x=1797460207; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=hHSX0hohRrlTX/MmckOgHs8gbau3qB7M/IquJtcvWa4=; b=ZnMGEIyfpj9ctUOiq8+yUSkLiX6zXebIFep5iyyn5HEnXG8x7/9ZC0+c uv2Up8TggkSmA65A+CNT0zLngSLumNCy5guG2N8K+ZDaMTy5SBJlECR09 i9BQYCAxjLRUEbmK6Il8na9+gbl8NHXS7RclvoyWcbfM/KSb7AoISQME4 mn8SRmAKvKohBaU25Gc/obnO6cXWrv/419NOF7duRUzPWYZ8gEXB1Cls5 x6Dh1WtvuAQJCzikVb2MzFdYgz4VnJynFd2/blWnxQxDrFp7fjociQyMn 9GhoKGxFfr/it4rxWQ9BJX+0r+X4+ker6n2CRCcca9WcN718naSxdDGr9 Q==; X-CSE-ConnectionGUID: WK9tf2OjQoa3iYcdfb5jaQ== X-CSE-MsgGUID: 8bDoK9TfRbqWlWcGI4kqvQ== X-IronPort-AV: E=McAfee;i="6800,10657,11644"; a="66841775" X-IronPort-AV: E=Sophos;i="6.21,154,1763452800"; d="scan'208";a="66841775" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Dec 2025 14:30:05 -0800 X-CSE-ConnectionGUID: tqOihI7iSpKox+rwR8RYhg== X-CSE-MsgGUID: m7tJr2Q1SEeVpxWpZo0H6Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,154,1763452800"; d="scan'208";a="202635974" Received: from schen9-mobl4.amr.corp.intel.com (HELO [10.125.110.205]) ([10.125.110.205]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Dec 2025 14:30:04 -0800 Message-ID: Subject: Re: [PATCH v2 01/23] sched/cache: Introduce infrastructure for cache-aware load balancing 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: Tue, 16 Dec 2025 14:30:03 -0800 In-Reply-To: References: <06f0d7edbc3185ec730b50b3b00d87ace44169b3.1764801860.git.tim.c.chen@linux.intel.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 Thu, 2025-12-11 at 16:42 +0800, Vern Hao wrote: > =C2=A0 >=20 >=20 >=20 >=20 snip > > + struct mm_sched __percpu *pcpu_sched; > > + raw_spinlock_t mm_sched_lock; > > + unsigned long mm_sched_epoch; > > + int mm_sched_cpu; > > =C2=A0 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > =C2=A0 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > As we discussed earlier=EF=BC=8CI continue to believe that dedicating 'mm= _sched_cpu' to handle the aggregated hotspots of all threads is inappropria= te, as the multiple threads lack a necessary correlation in our real applic= ation.=C2=A0 > =C2=A0 > So, I was wondering if we could put this variable into struct task_struct= , That allows us to better monitor the hotspot CPU of each thread, despite = some details needing consideration. > =C2=A0 >=20 >=20 Vern, The stat is related to the group of threads(tasks) that we will like to gro= up together in an LLC. In current implementation, it is per process and hence the placement in mm struct. Later, we could change the grouping to other criteria (e.g. cgroup, or numa= _group). In that case the stats may be associated with other data struct that represent the group. As I mentioned in the cover letter, that would be another exercise = and we'll like to get the basic grouping by process to be merged first before conside= ring other kinds of grouping. Tim >=20