Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection
On Fri, May 01, 2015 at 06:36:35PM -0700, Vikas Shivappa wrote: > +#define X86_FEATURE_RDT ( 9*32+15) /* Resource Allocation */ > +#define X86_FEATURE_CAT_L3 (13*32 + 1) /* Cache QOS Enforcement L3 */ > + /* Cache Allocation Technology values */ > + u16 x86_cat_cbmlength; > + u16 x86_cat_closs; At the very least be consistent with the silly TLA nonsense. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection
On Fri, May 01, 2015 at 06:36:35PM -0700, Vikas Shivappa wrote: +#define X86_FEATURE_RDT ( 9*32+15) /* Resource Allocation */ +#define X86_FEATURE_CAT_L3 (13*32 + 1) /* Cache QOS Enforcement L3 */ + /* Cache Allocation Technology values */ + u16 x86_cat_cbmlength; + u16 x86_cat_closs; At the very least be consistent with the silly TLA nonsense. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection
On Thu, Feb 26, 2015 at 11:12:28AM -0800, Vikas Shivappa wrote: > It would be easier to view the resources like CPUID availability > through cgroup interface itself rather than add an other interface for > the same. Right, exposing that info in the same place where it is being used/controlled makes most sense to me. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection
On Thu, 26 Feb 2015, Borislav Petkov wrote: On Thu, Feb 26, 2015 at 10:19:42AM -0800, Vikas Shivappa wrote: This would be an indication that the System support RDT. On a system with RDT would see a print. intel_rdt: cbmlength: xx , CLOss:xx Ok, so I have a capacity bitmask of length xx and yy classes of service. And? Are you expecting for tools or experienced users to grep dmesg to find that information? Uh, but what happens on a machine which has a small log buffer and which has wrapped around and that information has been overwritten? Yes, this is not the only way to see if the feature is enabled. It can be seen in cpuinfo like you mention below. The root's cbm mask represents the max cbm length already - that can be seen by the user as defined in the documentation. It is under consideration to add Max closids or something like clos ids available to be shown in the root cgroup once there are more resources and more such parameters required to be exposed to user. It would be easier to view the resources like CPUID availability through cgroup interface itself rather than add an other interface for the same. See what I mean? If you really want to communicate this information to someone, you should use more robust methods like make userspace use CPUID directly or expose that information in sysfs if CPUID is not an option (but I can't imagine why it wouldn't be). This flaky message which can get overwritten and gets used only by a small percentage of people(?) (I haven't reached the part which tells me the use cases for that resource management yet) is purely useless in dmesg. Even /proc/cpuinfo, which will have "rdt" et all in there according to the defines you're adding, would be a much better way to detect what's supported quickly than the message. HTH. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection
On Thu, Feb 26, 2015 at 10:19:42AM -0800, Vikas Shivappa wrote: > This would be an indication that the System support RDT. On a system with > RDT would see a print. > > intel_rdt: cbmlength: xx , CLOss:xx Ok, so I have a capacity bitmask of length xx and yy classes of service. And? Are you expecting for tools or experienced users to grep dmesg to find that information? Uh, but what happens on a machine which has a small log buffer and which has wrapped around and that information has been overwritten? See what I mean? If you really want to communicate this information to someone, you should use more robust methods like make userspace use CPUID directly or expose that information in sysfs if CPUID is not an option (but I can't imagine why it wouldn't be). This flaky message which can get overwritten and gets used only by a small percentage of people(?) (I haven't reached the part which tells me the use cases for that resource management yet) is purely useless in dmesg. Even /proc/cpuinfo, which will have "rdt" et all in there according to the defines you're adding, would be a much better way to detect what's supported quickly than the message. HTH. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection
On Wed, 25 Feb 2015, Borislav Petkov wrote:
On Tue, Feb 24, 2015 at 04:42:10PM -0800, Vikas Shivappa wrote:
+
+ pr_info("cbmlength:%u,Closs: %u\n", cbm_len, maxid);
This text message needs to be much more user-friendly if it is going out
to the console unconditionally.
bit mask lengh: number of CLOSids: ? . it should print with the module name
as well which should help understand what it is for.
Right, if I haven't read the SDM on RDT, I still don't understand what
those mean. What is the need for that message at all, what is it telling
me?
Can you show an example from a machine with RDT and explain what it is
good for?
This would be an indication that the System support RDT. On a system with RDT
would see a print.
intel_rdt: cbmlength: xx , CLOss:xx
This is documented in the RDT documentation that is added in the patch and the
code also mentiones the Intel SDM section which details the feature. The RDT
is expected to be used by advanced users atlest the ones who would use the
cgroup RDT interface , knows about the class of service , bit mask etc.. The use
cases are also documented in the RDT document in cgroups/rdt.txt (the last
patch in this series)
+config CGROUP_RDT
+ bool "Resource Director Technology cgroup subsystem"
+ depends on X86_64
depends on X86_64 && CPU_SUP_INTEL
Also, this should probably also depend on CGROUP-something or so
AFAICT...
This is with in the if CGROUPS
Right, but you still need the CPU_SUP_INTEL dependency as !Intel x86
doesn't need that code built.
Will add this dependency..
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection
On Wed, 25 Feb 2015, Borislav Petkov wrote: On Tue, Feb 24, 2015 at 04:42:10PM -0800, Vikas Shivappa wrote: + + pr_info(cbmlength:%u,Closs: %u\n, cbm_len, maxid); This text message needs to be much more user-friendly if it is going out to the console unconditionally. bit mask lengh: number of CLOSids: ? . it should print with the module name as well which should help understand what it is for. Right, if I haven't read the SDM on RDT, I still don't understand what those mean. What is the need for that message at all, what is it telling me? Can you show an example from a machine with RDT and explain what it is good for? This would be an indication that the System support RDT. On a system with RDT would see a print. intel_rdt: cbmlength: xx , CLOss:xx This is documented in the RDT documentation that is added in the patch and the code also mentiones the Intel SDM section which details the feature. The RDT is expected to be used by advanced users atlest the ones who would use the cgroup RDT interface , knows about the class of service , bit mask etc.. The use cases are also documented in the RDT document in cgroups/rdt.txt (the last patch in this series) +config CGROUP_RDT + bool Resource Director Technology cgroup subsystem + depends on X86_64 depends on X86_64 CPU_SUP_INTEL Also, this should probably also depend on CGROUP-something or so AFAICT... This is with in the if CGROUPS Right, but you still need the CPU_SUP_INTEL dependency as !Intel x86 doesn't need that code built. Will add this dependency.. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection
On Thu, 26 Feb 2015, Borislav Petkov wrote: On Thu, Feb 26, 2015 at 10:19:42AM -0800, Vikas Shivappa wrote: This would be an indication that the System support RDT. On a system with RDT would see a print. intel_rdt: cbmlength: xx , CLOss:xx Ok, so I have a capacity bitmask of length xx and yy classes of service. And? Are you expecting for tools or experienced users to grep dmesg to find that information? Uh, but what happens on a machine which has a small log buffer and which has wrapped around and that information has been overwritten? Yes, this is not the only way to see if the feature is enabled. It can be seen in cpuinfo like you mention below. The root's cbm mask represents the max cbm length already - that can be seen by the user as defined in the documentation. It is under consideration to add Max closids or something like clos ids available to be shown in the root cgroup once there are more resources and more such parameters required to be exposed to user. It would be easier to view the resources like CPUID availability through cgroup interface itself rather than add an other interface for the same. See what I mean? If you really want to communicate this information to someone, you should use more robust methods like make userspace use CPUID directly or expose that information in sysfs if CPUID is not an option (but I can't imagine why it wouldn't be). This flaky message which can get overwritten and gets used only by a small percentage of people(?) (I haven't reached the part which tells me the use cases for that resource management yet) is purely useless in dmesg. Even /proc/cpuinfo, which will have rdt et all in there according to the defines you're adding, would be a much better way to detect what's supported quickly than the message. HTH. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection
On Thu, Feb 26, 2015 at 10:19:42AM -0800, Vikas Shivappa wrote: This would be an indication that the System support RDT. On a system with RDT would see a print. intel_rdt: cbmlength: xx , CLOss:xx Ok, so I have a capacity bitmask of length xx and yy classes of service. And? Are you expecting for tools or experienced users to grep dmesg to find that information? Uh, but what happens on a machine which has a small log buffer and which has wrapped around and that information has been overwritten? See what I mean? If you really want to communicate this information to someone, you should use more robust methods like make userspace use CPUID directly or expose that information in sysfs if CPUID is not an option (but I can't imagine why it wouldn't be). This flaky message which can get overwritten and gets used only by a small percentage of people(?) (I haven't reached the part which tells me the use cases for that resource management yet) is purely useless in dmesg. Even /proc/cpuinfo, which will have rdt et all in there according to the defines you're adding, would be a much better way to detect what's supported quickly than the message. HTH. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection
On Thu, Feb 26, 2015 at 11:12:28AM -0800, Vikas Shivappa wrote: It would be easier to view the resources like CPUID availability through cgroup interface itself rather than add an other interface for the same. Right, exposing that info in the same place where it is being used/controlled makes most sense to me. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection
On Tue, Feb 24, 2015 at 04:42:10PM -0800, Vikas Shivappa wrote:
> >>+
> >>+ pr_info("cbmlength:%u,Closs: %u\n", cbm_len, maxid);
> >
> >This text message needs to be much more user-friendly if it is going out
> >to the console unconditionally.
> >
>
> bit mask lengh: number of CLOSids: ? . it should print with the module name
> as well which should help understand what it is for.
Right, if I haven't read the SDM on RDT, I still don't understand what
those mean. What is the need for that message at all, what is it telling
me?
Can you show an example from a machine with RDT and explain what it is
good for?
> >>+config CGROUP_RDT
> >>+ bool "Resource Director Technology cgroup subsystem"
> >>+ depends on X86_64
> >
> >depends on X86_64 && CPU_SUP_INTEL
> >
> >Also, this should probably also depend on CGROUP-something or so
> >AFAICT...
>
> This is with in the if CGROUPS
Right, but you still need the CPU_SUP_INTEL dependency as !Intel x86
doesn't need that code built.
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection
On Tue, Feb 24, 2015 at 04:42:10PM -0800, Vikas Shivappa wrote: + + pr_info(cbmlength:%u,Closs: %u\n, cbm_len, maxid); This text message needs to be much more user-friendly if it is going out to the console unconditionally. bit mask lengh: number of CLOSids: ? . it should print with the module name as well which should help understand what it is for. Right, if I haven't read the SDM on RDT, I still don't understand what those mean. What is the need for that message at all, what is it telling me? Can you show an example from a machine with RDT and explain what it is good for? +config CGROUP_RDT + bool Resource Director Technology cgroup subsystem + depends on X86_64 depends on X86_64 CPU_SUP_INTEL Also, this should probably also depend on CGROUP-something or so AFAICT... This is with in the if CGROUPS Right, but you still need the CPU_SUP_INTEL dependency as !Intel x86 doesn't need that code built. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection
On Tue, 24 Feb 2015, Borislav Petkov wrote:
On Tue, Feb 24, 2015 at 03:16:38PM -0800, Vikas Shivappa wrote:
-#define NCAPINTS 13 /* N 32-bit words worth of info */
+#define NCAPINTS 14 /* N 32-bit words worth of info */
#define NBUGINTS 1 /* N 32-bit bug flags */
/*
@@ -227,6 +227,7 @@
#define X86_FEATURE_RTM( 9*32+11) /* Restricted Transactional
Memory */
#define X86_FEATURE_CQM( 9*32+12) /* Cache QoS Monitoring */
#define X86_FEATURE_MPX( 9*32+14) /* Memory Protection
Extension */
+#define X86_FEATURE_RDT( 9*32+15) /* Resource Allocation */
#define X86_FEATURE_AVX512F( 9*32+16) /* AVX-512 Foundation */
#define X86_FEATURE_RDSEED ( 9*32+18) /* The RDSEED instruction */
#define X86_FEATURE_ADX( 9*32+19) /* The ADCX and ADOX
instructions */
@@ -248,6 +249,9 @@
/* Intel-defined CPU QoS Sub-leaf, CPUID level 0x000F:1 (edx), word 12 */
#define X86_FEATURE_CQM_OCCUP_LLC (12*32+ 0) /* LLC occupancy monitoring if 1
*/
+/* Intel-defined CPU features, CPUID level 0x0010:0 (ebx), word 13 */
+#define X86_FEATURE_CAT_L3 (13*32 + 1) /*Cache QOS Enforcement L3*/
Spaces between comment markers and text please.
Will fix.
+
/*
* BUG word(s)
*/
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 242ceed..81d95ac 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -114,6 +114,9 @@ struct cpuinfo_x86 {
int x86_cache_occ_scale;/* scale to bytes */
int x86_power;
unsigned long loops_per_jiffy;
+ /* Cache Allocation Technology values */
+ int x86_cat_cbmlength;
+ int x86_cat_closs;
Do I see it correctly, those two can be u16 each?
Yes , this can be u16 as the cbmlength and the number of clos are 4 and 16 bits
only. Will make the change
/* cpuid returned max cores value: */
u16 x86_max_cores;
u16 apicid;
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 6c1ca13..6c91e39 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_PERF_EVENTS_INTEL_UNCORE)+=
perf_event_intel_uncore.o \
perf_event_intel_uncore_nhmex.o
endif
+obj-$(CONFIG_CGROUP_RDT) +=intel_rdt.o
obj-$(CONFIG_X86_MCE) += mcheck/
obj-$(CONFIG_MTRR) += mtrr/
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 9b0fb70..c5ea1dd 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -668,6 +668,21 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
}
}
+ /* Additional Intel-defined flags: level 0x0010 */
+ if (c->cpuid_level >= 0x0010) {
+ u32 eax, ebx, ecx, edx;
+
+ cpuid_count(0x0010, 0, , , , );
+ c->x86_capability[13] = ebx;
+
+ if (cpu_has(c, X86_FEATURE_CAT_L3)) {
+
+ cpuid_count(0x0010, 1, , , , );
+ c->x86_cat_closs = (edx & 0x) + 1;
+ c->x86_cat_cbmlength = (eax & 0xf) + 1;
+ }
+ }
+
/* AMD-defined flags: level 0x8001 */
xlvl = cpuid_eax(0x8000);
c->extended_cpuid_level = xlvl;
diff --git a/arch/x86/kernel/cpu/intel_rdt.c b/arch/x86/kernel/cpu/intel_rdt.c
new file mode 100644
index 000..46ce449
--- /dev/null
+++ b/arch/x86/kernel/cpu/intel_rdt.c
@@ -0,0 +1,51 @@
+/*
+ * Resource Director Technology(RDT) code
+ *
+ * Copyright (C) 2014 Intel Corporation
+ *
+ * 2014-09-10 Written by Vikas Shivappa
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * More information about RDT be found in the Intel (R) x86 Architecture
+ * Software Developer Manual, section 17.15.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+
+static inline bool rdt_supported(struct cpuinfo_x86 *c)
+{
+ if (cpu_has(c, X86_FEATURE_RDT))
+ return true;
+
+ return false;
+}
+
+static int __init rdt_late_init(void)
+{
+ struct cpuinfo_x86 *c = _cpu_data;
+ int maxid, cbm_len;
+
+ if (!rdt_supported(c))
you can do cpu_has() directly here instead of the custom
Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection
On Tue, Feb 24, 2015 at 03:16:38PM -0800, Vikas Shivappa wrote:
> This patch adds support for the new Cache Allocation Technology (CAT)
> feature found in future Intel Xeon processors. CAT is part of Intel
> Resource Director Technology(RDT) which enables sharing of processor
> resources. This patch includes CPUID enumeration routines for CAT and
> new values to track CAT resources to the cpuinfo_x86 structure.
>
> Cache Allocation Technology(CAT) provides a way for the Software
> (OS/VMM) to restrict cache allocation to a defined 'subset' of cache
> which may be overlapping with other 'subsets'. This feature is used
> when allocating a line in cache ie when pulling new data into the cache.
> The programming of the h/w is done via programming MSRs.
>
> More information about CAT be found in the Intel (R) x86 Architecture
> Software Developer Manual, section 17.15.
>
> Signed-off-by: Vikas Shivappa
> ---
> arch/x86/include/asm/cpufeature.h | 6 -
> arch/x86/include/asm/processor.h | 3 +++
> arch/x86/kernel/cpu/Makefile | 1 +
> arch/x86/kernel/cpu/common.c | 15
> arch/x86/kernel/cpu/intel_rdt.c | 51
> +++
> init/Kconfig | 11 +
> 6 files changed, 86 insertions(+), 1 deletion(-)
> create mode 100644 arch/x86/kernel/cpu/intel_rdt.c
>
> diff --git a/arch/x86/include/asm/cpufeature.h
> b/arch/x86/include/asm/cpufeature.h
> index 54fd8eb..d97b785 100644
> --- a/arch/x86/include/asm/cpufeature.h
> +++ b/arch/x86/include/asm/cpufeature.h
> @@ -12,7 +12,7 @@
> #include
> #endif
>
> -#define NCAPINTS 13 /* N 32-bit words worth of info */
> +#define NCAPINTS 14 /* N 32-bit words worth of info */
> #define NBUGINTS 1 /* N 32-bit bug flags */
>
> /*
> @@ -227,6 +227,7 @@
> #define X86_FEATURE_RTM ( 9*32+11) /* Restricted Transactional
> Memory */
> #define X86_FEATURE_CQM ( 9*32+12) /* Cache QoS Monitoring */
> #define X86_FEATURE_MPX ( 9*32+14) /* Memory Protection
> Extension */
> +#define X86_FEATURE_RDT ( 9*32+15) /* Resource Allocation */
> #define X86_FEATURE_AVX512F ( 9*32+16) /* AVX-512 Foundation */
> #define X86_FEATURE_RDSEED ( 9*32+18) /* The RDSEED instruction */
> #define X86_FEATURE_ADX ( 9*32+19) /* The ADCX and ADOX
> instructions */
> @@ -248,6 +249,9 @@
> /* Intel-defined CPU QoS Sub-leaf, CPUID level 0x000F:1 (edx), word 12 */
> #define X86_FEATURE_CQM_OCCUP_LLC (12*32+ 0) /* LLC occupancy monitoring if
> 1 */
>
> +/* Intel-defined CPU features, CPUID level 0x0010:0 (ebx), word 13 */
> +#define X86_FEATURE_CAT_L3 (13*32 + 1) /*Cache QOS Enforcement L3*/
Spaces between comment markers and text please.
> +
> /*
> * BUG word(s)
> */
> diff --git a/arch/x86/include/asm/processor.h
> b/arch/x86/include/asm/processor.h
> index 242ceed..81d95ac 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -114,6 +114,9 @@ struct cpuinfo_x86 {
> int x86_cache_occ_scale;/* scale to bytes */
> int x86_power;
> unsigned long loops_per_jiffy;
> + /* Cache Allocation Technology values */
> + int x86_cat_cbmlength;
> + int x86_cat_closs;
Do I see it correctly, those two can be u16 each?
> /* cpuid returned max cores value: */
> u16 x86_max_cores;
> u16 apicid;
> diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
> index 6c1ca13..6c91e39 100644
> --- a/arch/x86/kernel/cpu/Makefile
> +++ b/arch/x86/kernel/cpu/Makefile
> @@ -47,6 +47,7 @@ obj-$(CONFIG_PERF_EVENTS_INTEL_UNCORE) +=
> perf_event_intel_uncore.o \
> perf_event_intel_uncore_nhmex.o
> endif
>
> +obj-$(CONFIG_CGROUP_RDT) +=intel_rdt.o
>
> obj-$(CONFIG_X86_MCE)+= mcheck/
> obj-$(CONFIG_MTRR) += mtrr/
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 9b0fb70..c5ea1dd 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -668,6 +668,21 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
> }
> }
>
> + /* Additional Intel-defined flags: level 0x0010 */
> + if (c->cpuid_level >= 0x0010) {
> + u32 eax, ebx, ecx, edx;
> +
> + cpuid_count(0x0010, 0, , , , );
> + c->x86_capability[13] = ebx;
> +
> + if (cpu_has(c, X86_FEATURE_CAT_L3)) {
> +
> + cpuid_count(0x0010, 1, , , , );
> + c->x86_cat_closs = (edx & 0x) + 1;
> + c->x86_cat_cbmlength = (eax & 0xf) + 1;
> + }
> + }
> +
> /* AMD-defined flags: level
Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection
On Tue, 24 Feb 2015, Borislav Petkov wrote:
On Tue, Feb 24, 2015 at 03:16:38PM -0800, Vikas Shivappa wrote:
-#define NCAPINTS 13 /* N 32-bit words worth of info */
+#define NCAPINTS 14 /* N 32-bit words worth of info */
#define NBUGINTS 1 /* N 32-bit bug flags */
/*
@@ -227,6 +227,7 @@
#define X86_FEATURE_RTM( 9*32+11) /* Restricted Transactional
Memory */
#define X86_FEATURE_CQM( 9*32+12) /* Cache QoS Monitoring */
#define X86_FEATURE_MPX( 9*32+14) /* Memory Protection
Extension */
+#define X86_FEATURE_RDT( 9*32+15) /* Resource Allocation */
#define X86_FEATURE_AVX512F( 9*32+16) /* AVX-512 Foundation */
#define X86_FEATURE_RDSEED ( 9*32+18) /* The RDSEED instruction */
#define X86_FEATURE_ADX( 9*32+19) /* The ADCX and ADOX
instructions */
@@ -248,6 +249,9 @@
/* Intel-defined CPU QoS Sub-leaf, CPUID level 0x000F:1 (edx), word 12 */
#define X86_FEATURE_CQM_OCCUP_LLC (12*32+ 0) /* LLC occupancy monitoring if 1
*/
+/* Intel-defined CPU features, CPUID level 0x0010:0 (ebx), word 13 */
+#define X86_FEATURE_CAT_L3 (13*32 + 1) /*Cache QOS Enforcement L3*/
Spaces between comment markers and text please.
Will fix.
+
/*
* BUG word(s)
*/
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 242ceed..81d95ac 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -114,6 +114,9 @@ struct cpuinfo_x86 {
int x86_cache_occ_scale;/* scale to bytes */
int x86_power;
unsigned long loops_per_jiffy;
+ /* Cache Allocation Technology values */
+ int x86_cat_cbmlength;
+ int x86_cat_closs;
Do I see it correctly, those two can be u16 each?
Yes , this can be u16 as the cbmlength and the number of clos are 4 and 16 bits
only. Will make the change
/* cpuid returned max cores value: */
u16 x86_max_cores;
u16 apicid;
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 6c1ca13..6c91e39 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_PERF_EVENTS_INTEL_UNCORE)+=
perf_event_intel_uncore.o \
perf_event_intel_uncore_nhmex.o
endif
+obj-$(CONFIG_CGROUP_RDT) +=intel_rdt.o
obj-$(CONFIG_X86_MCE) += mcheck/
obj-$(CONFIG_MTRR) += mtrr/
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 9b0fb70..c5ea1dd 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -668,6 +668,21 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
}
}
+ /* Additional Intel-defined flags: level 0x0010 */
+ if (c-cpuid_level = 0x0010) {
+ u32 eax, ebx, ecx, edx;
+
+ cpuid_count(0x0010, 0, eax, ebx, ecx, edx);
+ c-x86_capability[13] = ebx;
+
+ if (cpu_has(c, X86_FEATURE_CAT_L3)) {
+
+ cpuid_count(0x0010, 1, eax, ebx, ecx, edx);
+ c-x86_cat_closs = (edx 0x) + 1;
+ c-x86_cat_cbmlength = (eax 0xf) + 1;
+ }
+ }
+
/* AMD-defined flags: level 0x8001 */
xlvl = cpuid_eax(0x8000);
c-extended_cpuid_level = xlvl;
diff --git a/arch/x86/kernel/cpu/intel_rdt.c b/arch/x86/kernel/cpu/intel_rdt.c
new file mode 100644
index 000..46ce449
--- /dev/null
+++ b/arch/x86/kernel/cpu/intel_rdt.c
@@ -0,0 +1,51 @@
+/*
+ * Resource Director Technology(RDT) code
+ *
+ * Copyright (C) 2014 Intel Corporation
+ *
+ * 2014-09-10 Written by Vikas Shivappa
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * More information about RDT be found in the Intel (R) x86 Architecture
+ * Software Developer Manual, section 17.15.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME : fmt
+
+#include linux/slab.h
+#include linux/err.h
+#include linux/spinlock.h
+
+static inline bool rdt_supported(struct cpuinfo_x86 *c)
+{
+ if (cpu_has(c, X86_FEATURE_RDT))
+ return true;
+
+ return false;
+}
+
+static int __init rdt_late_init(void)
+{
+ struct cpuinfo_x86 *c = boot_cpu_data;
+ int maxid, cbm_len;
+
+ if (!rdt_supported(c))
you
Re: [PATCH 1/7] x86/intel_rdt: Intel Cache Allocation Technology detection
On Tue, Feb 24, 2015 at 03:16:38PM -0800, Vikas Shivappa wrote:
This patch adds support for the new Cache Allocation Technology (CAT)
feature found in future Intel Xeon processors. CAT is part of Intel
Resource Director Technology(RDT) which enables sharing of processor
resources. This patch includes CPUID enumeration routines for CAT and
new values to track CAT resources to the cpuinfo_x86 structure.
Cache Allocation Technology(CAT) provides a way for the Software
(OS/VMM) to restrict cache allocation to a defined 'subset' of cache
which may be overlapping with other 'subsets'. This feature is used
when allocating a line in cache ie when pulling new data into the cache.
The programming of the h/w is done via programming MSRs.
More information about CAT be found in the Intel (R) x86 Architecture
Software Developer Manual, section 17.15.
Signed-off-by: Vikas Shivappa vikas.shiva...@linux.intel.com
---
arch/x86/include/asm/cpufeature.h | 6 -
arch/x86/include/asm/processor.h | 3 +++
arch/x86/kernel/cpu/Makefile | 1 +
arch/x86/kernel/cpu/common.c | 15
arch/x86/kernel/cpu/intel_rdt.c | 51
+++
init/Kconfig | 11 +
6 files changed, 86 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/kernel/cpu/intel_rdt.c
diff --git a/arch/x86/include/asm/cpufeature.h
b/arch/x86/include/asm/cpufeature.h
index 54fd8eb..d97b785 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -12,7 +12,7 @@
#include asm/disabled-features.h
#endif
-#define NCAPINTS 13 /* N 32-bit words worth of info */
+#define NCAPINTS 14 /* N 32-bit words worth of info */
#define NBUGINTS 1 /* N 32-bit bug flags */
/*
@@ -227,6 +227,7 @@
#define X86_FEATURE_RTM ( 9*32+11) /* Restricted Transactional
Memory */
#define X86_FEATURE_CQM ( 9*32+12) /* Cache QoS Monitoring */
#define X86_FEATURE_MPX ( 9*32+14) /* Memory Protection
Extension */
+#define X86_FEATURE_RDT ( 9*32+15) /* Resource Allocation */
#define X86_FEATURE_AVX512F ( 9*32+16) /* AVX-512 Foundation */
#define X86_FEATURE_RDSEED ( 9*32+18) /* The RDSEED instruction */
#define X86_FEATURE_ADX ( 9*32+19) /* The ADCX and ADOX
instructions */
@@ -248,6 +249,9 @@
/* Intel-defined CPU QoS Sub-leaf, CPUID level 0x000F:1 (edx), word 12 */
#define X86_FEATURE_CQM_OCCUP_LLC (12*32+ 0) /* LLC occupancy monitoring if
1 */
+/* Intel-defined CPU features, CPUID level 0x0010:0 (ebx), word 13 */
+#define X86_FEATURE_CAT_L3 (13*32 + 1) /*Cache QOS Enforcement L3*/
Spaces between comment markers and text please.
+
/*
* BUG word(s)
*/
diff --git a/arch/x86/include/asm/processor.h
b/arch/x86/include/asm/processor.h
index 242ceed..81d95ac 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -114,6 +114,9 @@ struct cpuinfo_x86 {
int x86_cache_occ_scale;/* scale to bytes */
int x86_power;
unsigned long loops_per_jiffy;
+ /* Cache Allocation Technology values */
+ int x86_cat_cbmlength;
+ int x86_cat_closs;
Do I see it correctly, those two can be u16 each?
/* cpuid returned max cores value: */
u16 x86_max_cores;
u16 apicid;
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 6c1ca13..6c91e39 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_PERF_EVENTS_INTEL_UNCORE) +=
perf_event_intel_uncore.o \
perf_event_intel_uncore_nhmex.o
endif
+obj-$(CONFIG_CGROUP_RDT) +=intel_rdt.o
obj-$(CONFIG_X86_MCE)+= mcheck/
obj-$(CONFIG_MTRR) += mtrr/
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 9b0fb70..c5ea1dd 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -668,6 +668,21 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
}
}
+ /* Additional Intel-defined flags: level 0x0010 */
+ if (c-cpuid_level = 0x0010) {
+ u32 eax, ebx, ecx, edx;
+
+ cpuid_count(0x0010, 0, eax, ebx, ecx, edx);
+ c-x86_capability[13] = ebx;
+
+ if (cpu_has(c, X86_FEATURE_CAT_L3)) {
+
+ cpuid_count(0x0010, 1, eax, ebx, ecx, edx);
+ c-x86_cat_closs = (edx 0x) + 1;
+ c-x86_cat_cbmlength = (eax 0xf) + 1;
+ }
+ }
+
/* AMD-defined flags: level 0x8001 */
xlvl =
