RE: resctrl2 - status

quoted

quoted

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel