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 C6EAF30F80D for ; Mon, 15 Dec 2025 19:21:55 +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=1765826517; cv=none; b=Pjni+ayUnsbvtDmeUTm1uj2K4RuIC6RpM2upI92f+YJ6wdKHBKvKpHIiJUA5Wbvf1LgSDSYy4IF1TuAlSUKPHNBwN3zoooYDV22fOFsOs7idMG3JNe2rD/HGtNDrmvs9L1e3DpVL4A6sGxkB2LZTpU9q0DOYWne7pblfnWR+m98= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765826517; c=relaxed/simple; bh=D5/c0XVstImKfPEy4DkzcQu3S5lAXHXRiso73OJM3Cc=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=C2cZsaxtgXn7hq3QhnWlkgGAycIuzuu9wDtRMCnw/19VRinPotW+15n4UsRW2llKnmECItxvToRrS+jcttZwmgI1cwvHKgGdfr6sh2TYUd9o/a5akI/80Mh/LfLB4E6dTUkD8BdNcLbW+E3Ll4YS+/dTlrmr/BKrhWWxxJQrFAM= 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=lTI3qo3m; 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="lTI3qo3m" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1765826516; x=1797362516; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=D5/c0XVstImKfPEy4DkzcQu3S5lAXHXRiso73OJM3Cc=; b=lTI3qo3mSCAx8iCbj8tKwfl2ErNVio8GwLWoCO5LGyXXCth67vVxTcth GzIUkmF5J7NQ3YHot/x41AOJpjeMtA3JLRYJTHZ+g67zAcLbbyo319MOa b7DdfVCt5sbxuZO5yjyWqXLjrNhmPiTpMUiPBAJTCq5SH6hDfMShQ4RPT qXLEmuSKBnWmjjYukSHlj/Lgb7KEKTWUEqHJbVv7cSSXZGiNWyNBYoJeb 8oQFnx7o7AtkaV9+vUJMWlNK4pJvqDAuKacdbBua6hZu7de00ZgXzu8oh bP5ihm7L6uS3yXynKt2CbdTFswpEmL43P5CAC3YD8e5NERFkBZu3vZj82 A==; X-CSE-ConnectionGUID: eCUkKJ4BQZGd6YZAi/YYHA== X-CSE-MsgGUID: Pgw4bSCtSdC1HRg38hP0UQ== X-IronPort-AV: E=McAfee;i="6800,10657,11643"; a="66726168" X-IronPort-AV: E=Sophos;i="6.21,151,1763452800"; d="scan'208";a="66726168" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Dec 2025 11:21:55 -0800 X-CSE-ConnectionGUID: IvVZsePdR/Kc2RLX2zGGGg== X-CSE-MsgGUID: ha9WSFC6T46874Q0EyQCmw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,151,1763452800"; d="scan'208";a="228881770" Received: from schen9-mobl4.amr.corp.intel.com (HELO [10.125.110.163]) ([10.125.110.163]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Dec 2025 11:21:52 -0800 Message-ID: Subject: Re: [PATCH v2 07/23] sched/cache: Introduce per runqueue task LLC preference counter From: Tim Chen To: Peter Zijlstra Cc: Ingo Molnar , K Prateek Nayak , "Gautham R . Shenoy" , Vincent Guittot , 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 , 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:21:51 -0800 In-Reply-To: <20251211103150.GA3707891@noisy.programming.kicks-ass.net> References: <63091f7ca7bb473fbc176af86a87d27a07a6e149.1764801860.git.tim.c.chen@linux.intel.com> <20251210125114.GS3707891@noisy.programming.kicks-ass.net> <20251211103150.GA3707891@noisy.programming.kicks-ass.net> 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 11:31 +0100, Peter Zijlstra wrote: > On Wed, Dec 10, 2025 at 10:49:14AM -0800, Tim Chen wrote: > > On Wed, 2025-12-10 at 13:51 +0100, Peter Zijlstra wrote: > > > On Wed, Dec 03, 2025 at 03:07:26PM -0800, Tim Chen wrote: >=20 > > > Would it perhaps be easier to stick this thing in rq->sd rather than = in > > > rq->nr_pref_llc. That way it automagically switches with the 'new' > > > domain. And then, with a bit of care, a singe load-balance pass shoul= d > > > see a consistent view (there should not be reloads of rq->sd -- which > > > will be a bit of an audit I suppose). > >=20 > > We need nr_pref_llc information at the runqueue level because the load = balancer=C2=A0 > > must identify which specific rq has the largest number of tasks that=C2= =A0 > > prefer a given destination LLC. If we move the counter to the LLC=E2=80= =99s sd=C2=A0 > > level, we would only know the aggregate number of tasks in the entire L= LC=C2=A0 > > that prefer that destination=E2=80=94not which rq they reside on. Witho= ut per-rq=C2=A0 > > counts, we would not be able to select the correct source rq to pull ta= sks from. > >=20 > > The only way this could work at the LLC-sd level is if all CPUs within= =C2=A0 > > the LLC shared a single runqueue, which is not the case today. > >=20 > > Let me know if I understand your comments correctly. >=20 > So the sched_domain instances are per-cpu (hence the need for > sched_domain_shared). So irrespective of what level you stick them at (I > was thinking the bottom most, but it really doesn't matter) they will be > per CPU. >=20 Okay, I see what you're saying. Will update code accordingly. Tim