From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 4C76E1D5160 for ; Fri, 20 Feb 2026 16:03:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771603425; cv=none; b=GJjGomUPQ8zsFiIRfDZUi+JTWFEB/reEnQIdHsqiChS0uAi63tcGq6wnWP5ZszxvDrrj17Y6t9FQitNnJfPMjW+Y6aWLPn+HXa/FerX3hbXsqjTQHaVy+aW6wtd9d69Y4bZc1Xd10cll47YhxF8Q5Yz2bGgYJcjuAevksBL0AU8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771603425; c=relaxed/simple; bh=epL2zE6uKdyCFZLDrwAuyA46MEjcAIg7EnGuNm44jXc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SsqT02lJThFZMdRZviQelG3l4PTnfGYEU81kCh6Vj9mIkSQvvF9IPJB1rDj60nKqPCXd/e+R6WRisOXiacT0CgKYNFkqudZsdZYO3ATsNslGtDU4RtL0nLBrCvnqGuYXtWV9vc7+PuQlxbrOuDycrQTeGO8ywnuiBLfcHw/eZNI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=LHvdndzh; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="LHvdndzh" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=P/LajzsKli6qB7ManUGbbi4Jfvo26elSqVShmR6MNgE=; b=LHvdndzhnTbOt+rgmVRbzw5kJ/ 22IJk2oywFttCfb6rHZqSO1AKrvuOA3ru8XbB8vxdNANvpti+/tOoZiN7QeYdM4PbSwcYxULDPv5G SnpJJCnC4QPmSc3sstWyJdbR2TizcEfaqSy1n0edXZMC36IwQa4JQA+YPK6+JHBh4JIDsyNpkOwlu 10XlGhS61bXMLTZVWNcwhxyD6ORQrB4taBZY2rvoxfS9Atqvmso27SeFbpUFla2VmpSv1eQ19WmIt ZWUXzIyQKaRmXdci8atS8lmqXHEGaMiAFGwjNf6zno7F27iLHRFquc3qOFkouyebWJOoRx+IIaZk3 fx8z8fag==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vtSy5-00000009lek-3MAc; Fri, 20 Feb 2026 16:03:01 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 4CA65301BD5; Fri, 20 Feb 2026 17:03:00 +0100 (CET) Date: Fri, 20 Feb 2026 17:03:00 +0100 From: Peter Zijlstra To: "Chen, Yu C" Cc: Tim Chen , Ingo Molnar , "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 , Adam Li , Aaron Lu , Tim Chen , Josh Don , Gavin Guo , Qais Yousef , Libo Chen , linux-kernel@vger.kernel.org, K Prateek Nayak Subject: Re: [PATCH v3 04/21] sched/cache: Make LLC id continuous Message-ID: <20260220160300.GH2995752@noisy.programming.kicks-ass.net> References: <60a05a3f50d14a7bf3b968f62cca87893c5c552c.1770760558.git.tim.c.chen@linux.intel.com> <79755f7d-cc68-4189-b6d8-850378e54017@amd.com> <20260219154007.GI1395266@noisy.programming.kicks-ass.net> <2ffbceaa-f9ab-461a-8324-3f500fcf8786@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2ffbceaa-f9ab-461a-8324-3f500fcf8786@intel.com> On Fri, Feb 20, 2026 at 11:53:31PM +0800, Chen, Yu C wrote: > Hi Peter, > > On 2/19/2026 11:40 PM, Peter Zijlstra wrote: > > On Mon, Feb 16, 2026 at 01:14:20PM +0530, K Prateek Nayak wrote: > > [ ... ] > > > > +static int __sched_domains_alloc_llc_id(void) > > > +{ > > > + int lid; > > > + > > > + lockdep_assert_held(&sched_domains_mutex); > > > + > > > + lid = cpumask_first_zero(sched_domains_llc_id_allocmask); > > > + if (lid >= tl_max_llcs) > > > + tl_max_llcs++; > > > > Urgh,. should we not rather track the max lid? > > > > Do you mean we should not always increment the max lid, > but instead decrease it when an llc_id is released? > I think Tim has adjusted the code to shrink tl_max_llcs > when an llc_id is released: > https://lore.kernel.org/all/acc7a5c96e8235bf11af640798ce1b60bcaa8196.camel@linux.intel.com/ You can only shrink when the max lid is released. Since lid is an array index, something like max_lid = weight(mask) would be terribly broken. But what I was getting at is that the code as presented there is rather non-obvious. Yes, if the lid is higher, it cannot be more than one higher than the previous value, but something like: lid = cpumask_first_zero(); BUG_ON(lid >= nr_cpu_ids); max_lid = max(max_lid, lid); Is way simpler to follow since it doesn't have that hidden assumption. Then, if you want to allow shrinking, then the clear side could do something like: __cpumask_clear(lid, mask); if (lid == max_lid) max_lid = cpumask_last(mask); or something like that. > > Also, we allocate max_llc sized data structures, if this thing is > > 'variable' we must also always store a copy of the 'lid' size of the > > time of allocation. > > > > Do you mean we should save the latest llc_max in the sched_domain > and publish it during sd attachment, as suggested at: > > https://lore.kernel.org/all/20260220104533.GO1395266@noisy.programming.kicks-ass.net/ Yeah, having it separated like it is now feels super fragile.