Re: [PATCH v16 0/9] Add support for Sub-NUMA cluster (SNC) systems

[Reinette Chatre]

Hi Maciej,

On 3/20/2024 8:21 AM, Maciej Wieczor-Retman wrote:
> Hi Reinette,
> 
> On 2024-03-19 at 10:51:14 -0700, Reinette Chatre wrote:
>> What remains is the user interface that continues to gather opinions [3]. These new
>> discussions were prompted by user space needing a way to determine if resctrl supports
>> SNC. This started by using the "size" file but thinking about it more user space could
>> also look at whether the number of L3 control domains are different from the number
>> of L3 monitoring domains? I am adding Maciej for his opinion (please also include him
>> in future versions of this series). 
> 
> By this do you mean comparing the contents of main "schemata" file with the
> number of mon_L3_* files?

(assuming you mean mon_L3_* directories)

Yes, the "schemata" file can be used. There is also the "bit_usage" file in
the info directory that indicates how many control domains there are.
Do you think doing so also falls into the "not obvious text parsing and size
comparison" category?

> 
>> Apart from the user space requirement to know if SNC is supported by resctrl there
>> is also the interface with which user space obtains the monitoring data.
>> James highlighted [1] that the interface used in this series uses existing files to
>> represent different content, and can thus be considered as "broken". It is not obvious
>> to me how to "fix" this. Should we continue to explore interfaces like [2] that
>> attempts to add SNC support into resctrl or should the message continue to be
>> that SNC "plays havoc with the RDT monitoring features" and users wanting to use
>> SNC and RDT at the same time are expected to adapt to the peculiar interface ...
>> or is the preference that after this series "SNC and RDT are compatible" and
>> thus presented with an intuitive interface?
> 
> I kind of liked this idea [1]. Hiding SNC related information behind some not
> obvious text parsing and size comparisons might eliminate any ease of use for
> userspace applications. But I agree with you [2] that it's hard to predict the
> future for this interface and any potential problems with setting up this
> file structure.

Thanks to you for trying this out from user space side and highlighting the
difficulty trying to do so.

Reinette

> 
> [1] https://lore.kernel.org/all/SJ1PR11MB608309F47C00F964E16205D6FC2D2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
> [2] https://lore.kernel.org/all/7f15a700-f23a-48f9-b335-13ea1735ad84@xxxxxxxxx/
>