From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) (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 B6CCC212654 for ; Tue, 8 Oct 2024 18:50:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728413452; cv=none; b=fUg13NgeiuWtLXvBOK5tSnblI2fnN1iHSDdL7u3p3KoJIC4UBcvznZATZiqxxtxaFABaGmGSQOe3e5zCjSCVujAPp+1EIUe5csRKxsn5d2lkcwzec7kvUfrbicaRmZ31o923FHmHi9owSTuyRud0HzfQY10t19Ocvb0Vy1M5I1E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728413452; c=relaxed/simple; bh=DIJj9byAHXn1Kt1Dy4gur+QJCszeVGQqHdNoJHskiBs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cErZMZuJD36XsalwGb/Eio6FWK7mtB6u27LNPDnYX+AF+4ZXfXS7JY91TBswrRXTPz8wboagJPLfuO0Jso6MoeXGAADQpmCB0NajFnRijKb5gxkAbr2MxpnOHxb3hHgfMLie//ZwyFpzsyB3GEoeGVwKgfOHx/uKRuqF9HQ+RV0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=c5jxMQQU; arc=none smtp.client-ip=192.198.163.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="c5jxMQQU" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1728413451; x=1759949451; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=DIJj9byAHXn1Kt1Dy4gur+QJCszeVGQqHdNoJHskiBs=; b=c5jxMQQUAj6VkmA5TrrNNES3hemhU6Dh7dyXFKwJYRmZwNXMX1M0/SW3 fOEPh+0Wf1T2gaqZCFkRzwl8DpUqEU0lMebasbzbBR8IQBv/8NW6gkK+c gyjQU/gYR7xIfFmglLEeffd6GQqCtGEX4zskjVyfnsS9gxbKY6Lk1moOT Bb4J5trIlWFxekBTcJRpKdynniwTKcO/5X4uXX1lwuI64qEGMDzEsTeS9 ZKr16RIBJ1TpUkcmHjGr87Zv7VG2E9ogYDVEAb+hRjOsM2TsBuckl0YJw NBD4P8r3kxJsW9W+za+X58uKisbCYoW7Yak/eRQ1cEapPf+Q7uigQOlpo A==; X-CSE-ConnectionGUID: nsXrBPqvS2GVkVCXygPtyw== X-CSE-MsgGUID: BKCUQT3DQwuFiFkFQ4kRmw== X-IronPort-AV: E=McAfee;i="6700,10204,11219"; a="27097104" X-IronPort-AV: E=Sophos;i="6.11,187,1725346800"; d="scan'208";a="27097104" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2024 11:50:49 -0700 X-CSE-ConnectionGUID: ln1EamaCTESp6sjNiyrVDQ== X-CSE-MsgGUID: CZP2vg+ESx+f6xabEOwKeQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,187,1725346800"; d="scan'208";a="75905091" Received: from agluck-desk3.sc.intel.com ([172.25.222.70]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Oct 2024 11:50:48 -0700 Date: Tue, 8 Oct 2024 11:50:47 -0700 From: Tony Luck To: James Morse Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Fenghua Yu , Reinette Chatre , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , Babu Moger , shameerali.kolothum.thodi@huawei.com, D Scott Phillips OS , carl@os.amperecomputing.com, lcherian@marvell.com, bobo.shaobowang@huawei.com, tan.shaopeng@fujitsu.com, baolin.wang@linux.alibaba.com, Jamie Iles , Xin Hao , peternewman@google.com, dfustini@baylibre.com, amitsinght@marvell.com, David Hildenbrand , Rex Nie , Dave Martin , Shaopeng Tan Subject: Re: [PATCH v5 30/40] x86/resctrl: Describe resctrl's bitmap size assumptions Message-ID: References: <20241004180347.19985-1-james.morse@arm.com> <20241004180347.19985-31-james.morse@arm.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: <20241004180347.19985-31-james.morse@arm.com> On Fri, Oct 04, 2024 at 06:03:37PM +0000, James Morse wrote: > resctrl operates on configuration bitmaps and a bitmap of allocated > CLOSID, both are stored in a u32. > > MPAM supports configuration/portion bitmaps and PARTIDs larger > than will fit in a u32. > > Add some preprocessor values that make it clear why MPAM clamps > some of these values. This will make it easier to find code related > to these values if this resctrl behaviour ever changes. ... > +#define RESCTRL_MAX_CLOSID 32 Do you really need to do this? Intel x86 architecture allows for more than 32 CLOSIDs, it's just expensive in h/w to get past 16 ... so I picked that trivial bitmap allocator in ages past. But if ARM can have more, then why would you need to clamp the value? File system code could ask architecture code to allocate a CLOSID. On x86 that will fail when there are no more CLOSIDs, so filesystem will fail the mkdir(2). Or, since you put closid_alloc() into the filesystem code you could change the closid_free_map to u64. If you really do want to have this #define ... maybe you should use it in place of the hard coded 32 here: static void closid_init(void) { struct resctrl_schema *s; u32 rdt_min_closid = 32; } > +#define RESCTRL_MAX_CBM 32 Intel x86 could plausibly expand the cache bitmap size (the MSRs that store them currenly have bits 63:32 reserved, but that could be changed). The only 32-bit limits are the CPUID field that enumerates CBM_LEN and the CPUID field that enumerates the shared bitmap. The length has space for expansion, the share bitfiled does not. So if Intel did go to more than 32-bits we'd be stuck making sure any shared bits were in the lower 32-bits. -Tony