From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 B220F38F93D for ; Thu, 2 Apr 2026 10:55:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775127342; cv=none; b=hxPT2PYjp4cKjtHQz/ROVJgwUh/4lRHOCvCLRS5lM+/x4h4LSORGHK0FBJfTXWgC6Y4NYdRp2up4F1F0yzv2Y2id3C8q5xVKNW66o0rWKulO2E0KoAuLhvft3K85U0rFx1NIHQ8ui/0aUwYTzcIcESNkQT1XT3JfP17J/gJACXU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775127342; c=relaxed/simple; bh=sEiMiKWzWXVdenhXA+kBJndo1LHoJimexhkqmgDETOc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=O2lQJAiu6ZLM3kPeTskUXfw1bmXku+Wd/M6JTcXCJsmuhJpvwEkBTtJbDnbDbVwbKldsbLMlwVR/EGZf+LYNseJoEYwfv+/bSWRO0rI9ELRv0/jlYh6VdDTrWaZuuXeCuz4zry2IdrPYbNCXLxZOtjmfuw0Dcai5bjjcIIi1AR0= 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=mGayAxEy; arc=none smtp.client-ip=90.155.92.199 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="mGayAxEy" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; 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=jURJ08BnW/gMXR+cusGzLFj2y+fc2koynl1AhxVsjME=; b=mGayAxEytOOdsPwXvahTgbWjy2 iPmdMdr/DinhT3Hl2Q78covz/TSIHSgTowlveFkg3sZDLbkzhu5B5DRJVzdRtm2Rxk10Wwd/Kv2+o owiNT5/QGTG1V+AHGI++nhHQnypDWLkLB03zs8KYIxjhLFO7f+pihHn9hZKV4P3SnHNivtXD5u2xy 4RLCqmGWpTQPbLmVeLHCofkjaMIoOlOWAdtdOF9nFc7TBsTj0AeC/AnvC/0uerow6zVVc/BX04X9R wRLfebmZz2OUOsK3I5fIWENMfPtrrieYEjVuPD1ulODGN97Dj1u5/TIoRPCJ0h+CyUANS3DGsiRGk 4zYvtbjQ==; Received: from 2001-1c00-8d85-4b00-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:4b00:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1w8Fhz-00000002Gfc-1dBx; Thu, 02 Apr 2026 10:55:35 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id B36B930301D; Thu, 02 Apr 2026 12:55:30 +0200 (CEST) Date: Thu, 2 Apr 2026 12:55:30 +0200 From: Peter Zijlstra To: K Prateek Nayak Cc: "Chen, Yu C" , Tim Chen , Pan Deng , mingo@kernel.org, linux-kernel@vger.kernel.org, tianyou.li@intel.com Subject: Re: [PATCH v2 4/4] sched/rt: Split cpupri_vec->cpumask to per NUMA node to reduce contention Message-ID: <20260402105530.GA3738786@noisy.programming.kicks-ass.net> References: <20260320124003.GU3738786@noisy.programming.kicks-ass.net> <63a095f02428700a7ff2623b8ea81e524a406834.camel@linux.intel.com> <20260324120008.GB3738010@noisy.programming.kicks-ass.net> <138c3f9d-309f-41e6-aa72-a3f6bd713bf0@intel.com> <22072ef8-5aec-49ac-9cc4-8a80bec14261@amd.com> <64649c85-29ab-4f70-a0c4-3c83cbdae2fc@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: On Thu, Apr 02, 2026 at 10:11:11AM +0530, K Prateek Nayak wrote: > It is still not super clear to me how the logic deals with more than > 128CPUs in a DIE domain because that'll need more than the u64 but > sbm_find_next_bit() simply does: > > tmp = leaf->bitmap & mask; /* All are u64 */ > > expecting just the u64 bitmap to represent all the CPUs in the leaf. > > If we have, say 256 CPUs per DIE, we get shift(7) and arch_sbm_mask > as 7f (127) which allows a leaf to more than 64 CPUs but we are > using the "u64 bitmap" directly and not: > > find_next_bit(bitmap, arch_sbm_mask) > > Am I missing something here? Nope. That logic just isn't there, that was left as an exercise to the reader :-) For AMD in particular it would be good to have one leaf per CCD, but since CCD are not enumerated in your topology (they really should be), I didn't do that. Now, I seem to remember we had this discussion in the past some time, and you had some hacks available. Anyway, the whole premise was to have one leaf/cacheline per cache, such that high frequency atomic ops set/clear bit, don't bounce the line around. I took the nohz bitmap, because it was relatively simple and is known to suffer from contention under certain workloads.