Hi Tony,
On 5/22/2025 3:28 PM, Luck, Tony wrote:
On Thu, May 22, 2025 at 02:51:36PM -0500, Babu Moger wrote:
+/*
+ * resctrl_io_alloc_closid_get - io_alloc feature uses max CLOSID to route
+ * the IO traffic. Get the max CLOSID and verify if the CLOSID is available.
+ *
+ * The total number of CLOSIDs is determined in closid_init(), based on the
+ * minimum supported across all resources. If CDP (Code Data Prioritization)
+ * is enabled, the number of CLOSIDs is halved. The final value is returned
+ * by closids_supported(). Make sure this value aligns with the maximum
+ * CLOSID supported by the respective resource.
+ */
+static int resctrl_io_alloc_closid_get(struct rdt_resource *r)
+{
+ int num_closids = closids_supported();
+
+ if (resctrl_arch_get_cdp_enabled(r->rid))
+ num_closids *= 2;
+
+ if (num_closids != resctrl_arch_get_num_closid(r))
+ return -ENOSPC;
+
+ return closids_supported() - 1;
+}
Is using closids_supported() the right thing here? That's
the minimum value across all resources. So suppose you had
16 CLOS for the L3 resource, but only 8 CLOS in one of L2/MB/SMBA.
I'd assume the your h/w doesn't care that Linux chose to
ignore half of the available L3 CLOSIDs, and is still going
to use CLOSID==15 for SDCIA.
I think you'll take the -ENOSPC error return. But do you
really need to do that? Maybe you can still have SDCIA
enabled and using CLOSID 15?
We cannot support more than closids_supported(), as the bitmaps are not
initialized beyond that point, and other routines are also not designed
to handle more than closid_free_map_len.
While it's technically possible to implement a workaround for this
special case, it would be a hacky solution. It's likely unnecessary to
go down that path.
Thanks
Babu
