The CPU vendor IDs are required to be unique bits because they're used
for vendor_specific bitmask in the struct resctrl_test.
Consider for example their usage in test_vendor_specific_check():
return get_vendor() & test->vendor_specific
However, the definitions of CPU vendor IDs in file resctrl.h is quite
subtle as a bitmask value:
#define ARCH_INTEL 1
#define ARCH_AMD 2
A clearer and more maintainable approach is to define these CPU vendor
IDs using BIT(). This ensures each vendor corresponds to a distinct bit
and makes it obvious when adding new vendor IDs.
Accordingly, update the return types of detect_vendor() and get_vendor()
from 'int' to 'unsigned int' to align with their usage as bitmask values
and to prevent potentially risky type conversions.
Furthermore, introduce a bool flag 'initialized' to simplify the
get_vendor() -> detect_vendor() logic. This ensures the vendor ID is
detected only once and resolves the ambiguity of using the same variable
'vendor' both as a value and as a state.
Suggested-by: Reinette Chatre <reinette.chatre@intel.com>
Suggested-by: Fenghua Yu <fenghuay@nvidia.com>
Signed-off-by: Xiaochen Shen <shenxiaochen@open-hieco.net>
---
tools/testing/selftests/resctrl/resctrl.h | 7 ++---
.../testing/selftests/resctrl/resctrl_tests.c | 26 +++++++++++++------
2 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/tools/testing/selftests/resctrl/resctrl.h b/tools/testing/selftests/resctrl/resctrl.h
index cd3adfc14969..d0f094360e6f 100644
--- a/tools/testing/selftests/resctrl/resctrl.h
+++ b/tools/testing/selftests/resctrl/resctrl.h
@@ -23,6 +23,7 @@
#include <asm/unistd.h>
#include <linux/perf_event.h>
#include <linux/compiler.h>
+#include <linux/bits.h>
#include "../kselftest.h"
#define MB (1024 * 1024)
@@ -36,8 +37,8 @@
* Define as bits because they're used for vendor_specific bitmask in
* the struct resctrl_test.
*/
-#define ARCH_INTEL 1
-#define ARCH_AMD 2
+#define ARCH_INTEL BIT(0)
+#define ARCH_AMD BIT(1)
#define END_OF_TESTS 1
@@ -163,7 +164,7 @@ extern int snc_unreliable;
extern char llc_occup_path[1024];
int snc_nodes_per_l3_cache(void);
-int get_vendor(void);
+unsigned int get_vendor(void);
bool check_resctrlfs_support(void);
int filter_dmesg(void);
int get_domain_id(const char *resource, int cpu_no, int *domain_id);
diff --git a/tools/testing/selftests/resctrl/resctrl_tests.c b/tools/testing/selftests/resctrl/resctrl_tests.c
index 5154ffd821c4..08cbd094e936 100644
--- a/tools/testing/selftests/resctrl/resctrl_tests.c
+++ b/tools/testing/selftests/resctrl/resctrl_tests.c
@@ -23,16 +23,24 @@ static struct resctrl_test *resctrl_tests[] = {
&l2_noncont_cat_test,
};
-static int detect_vendor(void)
+static unsigned int detect_vendor(void)
{
- FILE *inf = fopen("/proc/cpuinfo", "r");
- int vendor_id = 0;
+ static bool initialized;
+ static unsigned int vendor_id;
+ FILE *inf;
char *s = NULL;
char *res;
- if (!inf)
+ if (initialized)
return vendor_id;
+ inf = fopen("/proc/cpuinfo", "r");
+ if (!inf) {
+ vendor_id = 0;
+ initialized = true;
+ return vendor_id;
+ }
+
res = fgrep(inf, "vendor_id");
if (res)
@@ -45,15 +53,17 @@ static int detect_vendor(void)
fclose(inf);
free(res);
+
+ initialized = true;
return vendor_id;
}
-int get_vendor(void)
+unsigned int get_vendor(void)
{
- static int vendor = -1;
+ unsigned int vendor;
+
+ vendor = detect_vendor();
- if (vendor == -1)
- vendor = detect_vendor();
if (vendor == 0)
ksft_print_msg("Can not get vendor info...\n");
--
2.47.3Hi Xiaochen,
On 12/10/25 10:46 PM, Xiaochen Shen wrote:
> The CPU vendor IDs are required to be unique bits because they're used
> for vendor_specific bitmask in the struct resctrl_test.
> Consider for example their usage in test_vendor_specific_check():
> return get_vendor() & test->vendor_specific
>
> However, the definitions of CPU vendor IDs in file resctrl.h is quite
> subtle as a bitmask value:
> #define ARCH_INTEL 1
> #define ARCH_AMD 2
>
> A clearer and more maintainable approach is to define these CPU vendor
> IDs using BIT(). This ensures each vendor corresponds to a distinct bit
> and makes it obvious when adding new vendor IDs.
>
> Accordingly, update the return types of detect_vendor() and get_vendor()
> from 'int' to 'unsigned int' to align with their usage as bitmask values
> and to prevent potentially risky type conversions.
>
> Furthermore, introduce a bool flag 'initialized' to simplify the
> get_vendor() -> detect_vendor() logic. This ensures the vendor ID is
> detected only once and resolves the ambiguity of using the same variable
> 'vendor' both as a value and as a state.
>
> Suggested-by: Reinette Chatre <reinette.chatre@intel.com>
> Suggested-by: Fenghua Yu <fenghuay@nvidia.com>
> Signed-off-by: Xiaochen Shen <shenxiaochen@open-hieco.net>
> ---
> tools/testing/selftests/resctrl/resctrl.h | 7 ++---
> .../testing/selftests/resctrl/resctrl_tests.c | 26 +++++++++++++------
> 2 files changed, 22 insertions(+), 11 deletions(-)
>
> diff --git a/tools/testing/selftests/resctrl/resctrl.h b/tools/testing/selftests/resctrl/resctrl.h
> index cd3adfc14969..d0f094360e6f 100644
> --- a/tools/testing/selftests/resctrl/resctrl.h
> +++ b/tools/testing/selftests/resctrl/resctrl.h
> @@ -23,6 +23,7 @@
> #include <asm/unistd.h>
> #include <linux/perf_event.h>
> #include <linux/compiler.h>
> +#include <linux/bits.h>
> #include "../kselftest.h"
>
> #define MB (1024 * 1024)
I tried this series against latest upstream kernel and found a conflict with some recent kselftest
refactoring via commit e6fbd1759c9e ("selftests: complete kselftest include centralization").
Usually the strategy for resctrl tests is to base them on "next" branch of
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git ... but I notice that the
conflicting change was routed differently and thus difficult to have anticipated.
Since we are in merge window the maintainer repos are not ready for new features yet.
Until the repo is ready, could you please base on latest upstream?
Looking at the series it is not obvious how you want these patches handled though. Patch #3
is the only one with a "Fixes:" tag (and thus candidate for automatic backport) but it is in
the middle of the series. It is usually best to have fixes at beginning of series to
simplify their handling. Even so, all patches are fixes but only patch #4 has a note
not to consider for backport. Could you please consider how you want these patches handled,
communicate that clearly in cover letter, and re-organize the series to have the ones needing
backport to be at beginning of series?
> @@ -36,8 +37,8 @@
> * Define as bits because they're used for vendor_specific bitmask in
> * the struct resctrl_test.
> */
> -#define ARCH_INTEL 1
> -#define ARCH_AMD 2
> +#define ARCH_INTEL BIT(0)
> +#define ARCH_AMD BIT(1)
>
> #define END_OF_TESTS 1
>
> @@ -163,7 +164,7 @@ extern int snc_unreliable;
> extern char llc_occup_path[1024];
>
> int snc_nodes_per_l3_cache(void);
> -int get_vendor(void);
> +unsigned int get_vendor(void);
> bool check_resctrlfs_support(void);
> int filter_dmesg(void);
> int get_domain_id(const char *resource, int cpu_no, int *domain_id);
> diff --git a/tools/testing/selftests/resctrl/resctrl_tests.c b/tools/testing/selftests/resctrl/resctrl_tests.c
> index 5154ffd821c4..08cbd094e936 100644
> --- a/tools/testing/selftests/resctrl/resctrl_tests.c
> +++ b/tools/testing/selftests/resctrl/resctrl_tests.c
> @@ -23,16 +23,24 @@ static struct resctrl_test *resctrl_tests[] = {
> &l2_noncont_cat_test,
> };
>
> -static int detect_vendor(void)
> +static unsigned int detect_vendor(void)
> {
> - FILE *inf = fopen("/proc/cpuinfo", "r");
> - int vendor_id = 0;
> + static bool initialized;
> + static unsigned int vendor_id;
> + FILE *inf;
Please maintain the reverse fir ordering.
> char *s = NULL;
> char *res;
>
> - if (!inf)
> + if (initialized)
> return vendor_id;
>
> + inf = fopen("/proc/cpuinfo", "r");
> + if (!inf) {
> + vendor_id = 0;
> + initialized = true;
> + return vendor_id;
> + }
> +
> res = fgrep(inf, "vendor_id");
>
> if (res)
> @@ -45,15 +53,17 @@ static int detect_vendor(void)
>
> fclose(inf);
> free(res);
> +
> + initialized = true;
> return vendor_id;
> }
>
> -int get_vendor(void)
> +unsigned int get_vendor(void)
> {
> - static int vendor = -1;
> + unsigned int vendor;
> +
> + vendor = detect_vendor();
>
> - if (vendor == -1)
> - vendor = detect_vendor();
> if (vendor == 0)
> ksft_print_msg("Can not get vendor info...\n");
>
Patch looks good to me.
Thank you
Reinette
Hi Reinette,
On 12/12/2025 1:22 PM, Reinette Chatre wrote:
> I tried this series against latest upstream kernel and found a conflict with some recent kselftest
> refactoring via commit e6fbd1759c9e ("selftests: complete kselftest include centralization").
Thank you for pointing out this issue.
I will rebase on top of the latest upstream kernel.
>
> Usually the strategy for resctrl tests is to base them on "next" branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git ... but I notice that the
> conflicting change was routed differently and thus difficult to have anticipated.
Thank you for the information.
>
> Since we are in merge window the maintainer repos are not ready for new features yet.
> Until the repo is ready, could you please base on latest upstream?
No problem. Thank you.
I will rebase on top of the latest upstream kernel, and then send out v4 patch series.
>
> Looking at the series it is not obvious how you want these patches handled though. Patch #3
> is the only one with a "Fixes:" tag (and thus candidate for automatic backport) but it is in
> the middle of the series. It is usually best to have fixes at beginning of series to
> simplify their handling. Even so, all patches are fixes but only patch #4 has a note
Thank you. I will re-organize the patch series to move patch #3 to the beginning of series.
> not to consider for backport. Could you please consider how you want these patches handled,
> communicate that clearly in cover letter, and re-organize the series to have the ones needing
> backport to be at beginning of series?
Thank you for your great suggestions.
I plan to add the maintainer notes in patch #1, patch #2, patch #4 (in original patch ordering in v3) and cover letter:
Patch #1 (this patch):
In my opinion, it is an improvement (to these two commits) rather than a real fix:
commit 6220f69e72a5 ("selftests/resctrl: Extend CPU vendor detection")
commit c603ff5bb830 ("selftests/resctrl: Introduce generalized test framework")
What do you think?
If you agree with me, I plan to add a maintainer note that it is not a candidate for backport in v4 patch series.
Patch #2:
This patch is not a candidate for backport. I will add a maintainer note in v4 patch series:
---------------------------
Maintainer note:
Even though this is a fix it is not a candidate for backport since it is
based on another patch series (x86/resctrl: Fix Platform QoS issues for
Hygon) which is in process of being added to resctrl.
---------------------------
Patch #3:
A candidate for backport with "Fixes:" tag. I will move this patch to the beginning of series.
Patch #4:
Already has a maintainer note. Keep no change.
Cover letter:
I plan to add a maintainer note outlining how I'd like these patches to be handled.
>> -static int detect_vendor(void)
>> +static unsigned int detect_vendor(void)
>> {
>> - FILE *inf = fopen("/proc/cpuinfo", "r");
>> - int vendor_id = 0;
>> + static bool initialized;
>> + static unsigned int vendor_id;
>> + FILE *inf;
> Please maintain the reverse fir ordering.
Thank you. I will fix this issue.
Best regards,
Xiaochen Shen
Hi Xiaochen,
On 12/11/25 11:32 PM, Xiaochen Shen wrote:
> On 12/12/2025 1:22 PM, Reinette Chatre wrote:
..
>
>
>> not to consider for backport. Could you please consider how you want these patches handled,
>> communicate that clearly in cover letter, and re-organize the series to have the ones needing
>> backport to be at beginning of series?
>
> Thank you for your great suggestions.
>
> I plan to add the maintainer notes in patch #1, patch #2, patch #4 (in original patch ordering in v3) and cover letter:
>
> Patch #1 (this patch):
> In my opinion, it is an improvement (to these two commits) rather than a real fix:
> commit 6220f69e72a5 ("selftests/resctrl: Extend CPU vendor detection")
> commit c603ff5bb830 ("selftests/resctrl: Introduce generalized test framework")
>
> What do you think?
> If you agree with me, I plan to add a maintainer note that it is not a candidate for backport in v4 patch series.
I agree with you. Patch #1 is an enhancement and preparatory patch for patch #2.
>
> Patch #2:
> This patch is not a candidate for backport. I will add a maintainer note in v4 patch series:
> ---------------------------
> Maintainer note:
> Even though this is a fix it is not a candidate for backport since it is
> based on another patch series (x86/resctrl: Fix Platform QoS issues for
> Hygon) which is in process of being added to resctrl.
> ---------------------------
>
> Patch #3:
> A candidate for backport with "Fixes:" tag. I will move this patch to the beginning of series.
>
> Patch #4:
> Already has a maintainer note. Keep no change.
>
> Cover letter:
> I plan to add a maintainer note outlining how I'd like these patches to be handled.
Since you describe how patches are to be handled in the cover letter the maintainer
notes in individual patches are not necessary. It does no harm though and no problem if
you prefer to keep them.
Thank you.
Reinette
© 2016 - 2025 Red Hat, Inc.