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 29AEB361DC5 for ; Fri, 20 Mar 2026 12:40:08 +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=1774010417; cv=none; b=UVsP2cUbxS0FZ5oc6TjtenmKevZ72UmhQxfcHbF5G/m7mIs87YMzhRKiv2WW6zpyNSvwiMYw1g58cWqwbPBQcfwMQldVZ+LkHoLayJME+GCIpTKu7FNCy+9yOIUiySA8v0vlleMJiV8DMkQDidn7Rdum/XMW6YHJqdrNi3/pvdo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774010417; c=relaxed/simple; bh=pkcIfmnIMIDP/GsmF+25vBrqBCDeAHs1igGAo3cP8Zw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fg43dzX3tvue2jOhdYACfw55c3C7jt2BioeXVceieU0kEzLuigwECIk2ywSH0JxJsd7kGbK0fHSLv4AUDGJTBU1LLOp23XdOZztCM25xDWYHCg1Ymo9HhYkNb5hmHk44lAEzCK8xiq+L/oRsXL50f9PqxQAcoOnHY5U3qfp9u50= 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=cKW3ikov; 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="cKW3ikov" 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=pkcIfmnIMIDP/GsmF+25vBrqBCDeAHs1igGAo3cP8Zw=; b=cKW3ikovI1RMip++rjuiMdP8oM 0wugosOmpx3ol+rrF9ALXU9S+MTzdsrpLYpMbxepmbblpzVqQ6iV1HW8XuxHl+hFe5tBOmshwCwq0 uieiONWkt83jtFGqoxKGlUr88n5if6GqIO5Yt7aIOo4tkI8PDNA6av/z1IMMRAtglrW53exF7lC74 gD9FIBa7qvwTLMT2QZ8NIg0xWGky9pxcyuZVIqkJrhXWRZXDNELjCbxNG0P8mNSiWsX995t8sPLrJ P/BeWodJfLXom5BujZbjZJ38gAwStywioQzRioM9JnJ6fAj9tGkWqOB6p8IMlz8fQwX/bdhWQruTp PxVo50Yw==; Received: from 2001-1c00-8d85-5700-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:5700:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1w3Z93-00000007lmW-16Xf; Fri, 20 Mar 2026 12:40:05 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id A53CB300578; Fri, 20 Mar 2026 13:40:03 +0100 (CET) Date: Fri, 20 Mar 2026 13:40:03 +0100 From: Peter Zijlstra To: Pan Deng Cc: mingo@kernel.org, linux-kernel@vger.kernel.org, tianyou.li@intel.com, tim.c.chen@linux.intel.com, yu.c.chen@intel.com Subject: Re: [PATCH v2 4/4] sched/rt: Split cpupri_vec->cpumask to per NUMA node to reduce contention Message-ID: <20260320124003.GU3738786@noisy.programming.kicks-ass.net> References: 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 Mon, Jul 21, 2025 at 02:10:26PM +0800, Pan Deng wrote: > This change splits `cpupri_vec->cpumask` into per-NUMA-node data to > mitigate false sharing. So I really do think we need something here. We're running into the whole cpumask contention thing on a semi regular basis. But somehow I doubt this is it. I would suggest building a radix tree like structure based on ACPIID -- which is inherently suitable for this given that is exactly how CPUID-0b/1f are specified. This of course makes it very much x86 specific, but perhaps other architectures can provide similarly structured id spaces suitable for this. If you make it so that it reduces to a single large level (equivalent to the normal bitmaps) when no intermediate masks are specific, it should work for all, and then architectures can opt-in by providing a suitable id space and masks.