RE: resctrl2 - status

[Luck, Tony]

> >> Alternatively, can user space just take a "load all resctrl modules
> >> and see what sticks" (even modules of different architectures since
> >> a user space may want to be generic) approach?
> >
> > This mostly works. Except for the cases where different modules access
> > the same underlying hardware, so can't be loaded together.
> >
> > Examples:
> >
> > rdt_l3_cat vs. rdt_l3_cdp - user needs to decide whether they want CDP or not.
> > But this is already true ... they have to decide whether to pass the "-o cdp" option
> > to mount.
> >
> > rdt_l3_mba vs. rdt_l3_mba_MBps - does the user want to control memory bandwidth
> > with percentages, or with MB/sec values. Again the user already has to make this
> > decision when choosing mount options.
> >
> >
> > Maybe the "What resctrl options does this machine support?" question would be
> > best answered with a small utility?
>
> A user space utility or a kernel provided utility? If it is a user space utility
> I think it would end up needing to duplicate what the kernel is required to do
> to know if a particular feature is supported. It seems appropriate that this
> could be a kernel utility that can share this existing information with user
> space. resctrl already supports the interface for this via /sys/fs/resctrl/info.

I was imagining a user space utility. Even though /proc/cpuinfo doesn't show
all features, a utility has access to all the CPUID leaves that contain the
details of each feature enumeration.

> fyi ... as with previous attempts to discuss this work I find it difficult
> to discuss this work when you are selective about what you want to discuss/answer
> and just wipe the rest. Through this I understand that I am not your target
> audience.

Not my intent. I value your input highly. I'm maybe too avid a follower of the
"trim your replies" school of e-mail etiquette. I thought I'd covered the gist
of your message.

I'll try to be more thorough in responding in the future.

-Tony