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 730B927E7F0 for ; Wed, 10 Dec 2025 18:49:17 +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=1765392559; cv=none; b=d0WFc0oj19eNLTvCVjvrnaFlC6lVSiem4AwrA5HHc56KillwJBGdJ/eopcz/S5UIlaKwnRMmWWRKHax6cvc5VOEG7pumPOb9QIWKxbS8EEx3rCvSHBCu7VBxEASc0sk6sWzCs+47OLebXb1I/iYa7wDZJjbMj93Ia0BAoYTCLBY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765392559; c=relaxed/simple; bh=QqEfh5JZTJfKRs+p6L9yX1yJ3DVZjAdqY4UoGdr6egU=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=evxHTyCGB4cd+h7wFDEbweZteJlVPTxytQkZwsMZiUjjAqBZSCgQ/lG7I1fb0lbdOwDkSeDQWy1iztN3Fe/QvvuvUOc9CyOoyQefPDd7qcfwbAszU4SKf0KgMeo38cj/KGz8BzgWFM5Yy5v35p1POxYPb9lNzCH2sTPkJ4lNHd8= 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=hc0k6rQQ; 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="hc0k6rQQ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1765392558; x=1796928558; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=QqEfh5JZTJfKRs+p6L9yX1yJ3DVZjAdqY4UoGdr6egU=; b=hc0k6rQQIxpU3l7SSR/2MgSQGyTUk7wtFtkRXUCTPJrNB6vvdnxfm8tW smTr9zldS2b3R2TW2BcfSzq899rj+uB+Wtw7WNvbjj7FUUw4AOaGIJnSc 6oQLWQ25qywyFd08mLtyej3Ce7VW2maW7Ab5OU9J6daekKq2NxHe7enOk ZIEblGuTRiHOngwwOhKPo054jCVRc1QVZZnHxHeBFhpQkEBHXasDWMEhh yp28XdnIMWE/lJmpIKHODBrYTxoaXPjeERGnSJWtB3K16FU6Rl1Orb+fb GbQv36sx/G38dnDmzZQa9LnzgENTlH3yxfxYkAIc2UvqSsCfxWz6LLuYF g==; X-CSE-ConnectionGUID: WGUuQG6CSbKIq2Jx70SEYw== X-CSE-MsgGUID: 8vM1A6aeSxSBnuHfOnxslg== X-IronPort-AV: E=McAfee;i="6800,10657,11638"; a="70994772" X-IronPort-AV: E=Sophos;i="6.20,264,1758610800"; d="scan'208";a="70994772" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Dec 2025 10:49:17 -0800 X-CSE-ConnectionGUID: UYN5Q1iQTFik0itPfOe22w== X-CSE-MsgGUID: 80q/FJadTmCjtZQaVwOZ4w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.20,264,1758610800"; d="scan'208";a="197083223" Received: from unknown (HELO [10.241.243.18]) ([10.241.243.18]) by fmviesa009-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Dec 2025 10:49:15 -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: Wed, 10 Dec 2025 10:49:14 -0800 In-Reply-To: <20251210125114.GS3707891@noisy.programming.kicks-ass.net> References: <63091f7ca7bb473fbc176af86a87d27a07a6e149.1764801860.git.tim.c.chen@linux.intel.com> <20251210125114.GS3707891@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 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 > > +static int resize_llc_pref(void) > > +{ > > + unsigned int *__percpu *tmp_llc_pref; > > + int i, ret =3D 0; > > + > > + if (new_max_llcs <=3D max_llcs) > > + return 0; > > + > > + /* > > + * Allocate temp percpu pointer for old llc_pref, > > + * which will be released after switching to the > > + * new buffer. > > + */ > > + tmp_llc_pref =3D alloc_percpu_noprof(unsigned int *); > > + if (!tmp_llc_pref) > > + return -ENOMEM; > > + > > + for_each_present_cpu(i) > > + *per_cpu_ptr(tmp_llc_pref, i) =3D NULL; > > + > > + /* > > + * Resize the per rq nr_pref_llc buffer and > > + * switch to this new buffer. > > + */ > > + for_each_present_cpu(i) { > > + struct rq_flags rf; > > + unsigned int *new; > > + struct rq *rq; > > + > > + rq =3D cpu_rq(i); > > + new =3D alloc_new_pref_llcs(rq->nr_pref_llc, per_cpu_ptr(tmp_llc_pre= f, i)); > > + if (!new) { > > + ret =3D -ENOMEM; > > + > > + goto release_old; > > + } > > + > > + /* > > + * Locking rq ensures that rq->nr_pref_llc values > > + * don't change with new task enqueue/dequeue > > + * when we repopulate the newly enlarged array. > > + */ > > + rq_lock_irqsave(rq, &rf); > > + populate_new_pref_llcs(rq->nr_pref_llc, new); > > + rq->nr_pref_llc =3D new; > > + rq_unlock_irqrestore(rq, &rf); > > + } > > + > > +release_old: > > + /* > > + * Load balance is done under rcu_lock. > > + * Wait for load balance before and during resizing to > > + * be done. They may refer to old nr_pref_llc[] > > + * that hasn't been resized. > > + */ > > + synchronize_rcu(); > > + for_each_present_cpu(i) > > + kfree(*per_cpu_ptr(tmp_llc_pref, i)); > > + > > + free_percpu(tmp_llc_pref); > > + > > + /* succeed and update */ > > + if (!ret) > > + max_llcs =3D new_max_llcs; > > + > > + return ret; > > +} >=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 should > see a consistent view (there should not be reloads of rq->sd -- which > will be a bit of an audit I suppose). We need nr_pref_llc information at the runqueue level because the load bala= ncer=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 LLC= =C2=A0 that prefer that destination=E2=80=94not which rq they reside on. Without p= er-rq=C2=A0 counts, we would not be able to select the correct source rq to pull tasks = from. 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. Let me know if I understand your comments correctly. Tim