e
never gone to the trouble of inventing the XFD hardware to support
the kernel's lazy 8KB buffer allocation.
cheers,
Len Brown, Intel Open Source Technology Center
red to probe for AMX and use AMX on AMX hardware.
Sort of hard to imagine with the programs above that we know today,
but future programs
certainly could do this if they chose to.
thanks,
Len Brown, Intel Open Source Technology Center
published as early as possible. However, if
you are really
nto the details of how AMX works, you may also be interested to know
that the AMX hardware patent filings are fully public ;-)
cheers,
Len Brown, Intel Open Source Technology Center
> I get it. That does not explain why LDMXCSR and VLDMXCSR cause
> pipelines stalls.
Sorry, I thought this thread was about AMX.
I don't know the answer to your LDMXCSR and VLDMXCSR question.
;establishing" part and was asking
> where we have established anything wrt AMX.
The patch set on LKML establishes working AMX Linux support in public.
I am thankful for your and other public review and feedback on that series.
I can think of 3 actual bugs that were found in the process.
thanks,
Len Brown Intel Open Source Technology Center
On Thu, Apr 15, 2021 at 12:24 PM Andy Lutomirski wrote:
> On Wed, Apr 14, 2021 at 2:48 PM Len Brown wrote:
> > > ... the transition penalty into and out of AMX code
The concept of 'transition' exists between AVX and SSE instructions
because it is possible to mix both instruction se
On Wed, Apr 14, 2021 at 5:58 AM Borislav Petkov wrote:
>
> On Tue, Apr 13, 2021 at 03:51:50PM -0400, Len Brown wrote:
> > AMX does the type of matrix multiplication that AI algorithms use. In
> > the unlikely event that you or one of the libraries you call are doing
>
ainly do this. The question is if it is important enough to bother.
What applications would notice if signal handlers were faster?
Would those applications be willing to update to opt-in to a
new incompatible signal handling ABI, where the kernel
took the time to supply only the state that they request?
thanks,
Len Brown, Intel Open Source Technology Center
On Tue, Apr 13, 2021 at 4:16 PM Andy Lutomirski wrote:
>
> On Mon, Apr 12, 2021 at 4:46 PM Len Brown wrote:
> >
> > On Mon, Apr 12, 2021 at 11:21 AM Andy Lutomirski wrote:
> >
> > > AMX: Multiplying a 4x4 matrix probably looks *great* in a
> > > micro
with
a poor AVX-512 hardware implementation. FWIW. I'm not aware of any
plans to implicitly use AMX this way, and I'm not aware of any non-Xeon
AMX implementations in the near future.
cheers,
Len Brown, Intel Open Source Technology Center
we can do that.
Let me know if you think of others,
thanks,
Len Brown,
Intel Open Source Technology Center
iscussion among userspace
> people is needed.
At the risk of stating the obvious...
Intel's view is that libraries that deliver the most value from the
hardware are a "good thing",
and that anything preventing libraries from getting the most value
from the hardware is a "bad thing&
On Fri, Apr 9, 2021 at 5:44 PM Andy Lutomirski wrote:
>
> On Fri, Apr 9, 2021 at 1:53 PM Len Brown wrote:
> >
> > On Wed, Mar 31, 2021 at 6:45 PM Andy Lutomirski wrote:
> > >
> > > On Wed, Mar 31, 2021 at 3:28 PM Len Brown wrote:
> > >
> &
On Wed, Mar 31, 2021 at 6:54 PM Borislav Petkov wrote:
>
> On Wed, Mar 31, 2021 at 06:28:27PM -0400, Len Brown wrote:
> > dynamic XCR0 breaks the installed base, I thought we had established
> > that.
>
> We should do a clear cut and have legacy stuff which has i
On Wed, Mar 31, 2021 at 6:45 PM Andy Lutomirski wrote:
>
> On Wed, Mar 31, 2021 at 3:28 PM Len Brown wrote:
>
> > We added compiler annotation for user-level interrupt handlers.
> > I'm not aware of it failing, or otherwise being confused.
>
> I followed your link
On Wed, Mar 31, 2021 at 12:53 PM Andy Lutomirski wrote:
> But this whole annotation thing will require serious compiler support.
> We already have problems with compilers inlining functions and getting
> confused about attributes.
We added compiler annotation for user-level interrupt handlers.
umerated, it really needs to also be turned off.
cheers,
--Len Brown, Intel Open Source Technology Center
ignal handler would opt-out
of some legacy signal capibilities. Complete state is one of them,
and thus long-jump is not supported, because the complete state
may not automatically be available.
thanks,
Len Brown, Intel Open Source Technology Center
On Tue, Mar 30, 2021 at 4:20 PM Andy Lutomirski wrote:
>
>
> > On Mar 30, 2021, at 12:12 PM, Dave Hansen wrote:
> >
> > On 3/30/21 10:56 AM, Len Brown wrote:
> >> On Tue, Mar 30, 2021 at 1:06 PM Andy Lutomirski
> >> wrote:
> >&g
On Tue, Mar 30, 2021 at 1:06 PM Andy Lutomirski wrote:
> > On Mar 30, 2021, at 10:01 AM, Len Brown wrote:
> > Is it required (by the "ABI") that a user program has everything
> > on the stack for user-space XSAVE/XRESTOR to get back
> > to the state of
Andy,
I agree, completely, with your description of the challenge,
thank you for focusing the discussion on that problem statement.
Question:
Is it required (by the "ABI") that a user program has everything
on the stack for user-space XSAVE/XRESTOR to get back
to the state of the program just
On Tue, Mar 30, 2021 at 4:28 AM Thomas Gleixner wrote:
>
> Len,
>
> On Mon, Mar 29 2021 at 18:16, Len Brown wrote:
> > On Mon, Mar 29, 2021 at 2:49 PM Thomas Gleixner wrote:
> > Let me know if this problem description is fair:
> >
> > Many-core Xeon serv
On Mon, Mar 29, 2021 at 2:16 PM Andy Lutomirski wrote:
>
>
> > On Mar 29, 2021, at 8:47 AM, Len Brown wrote:
> >
> > On Sat, Mar 27, 2021 at 5:58 AM Greg KH wrote:
> >>> On Fri, Mar 26, 2021 at 11:39:18PM -0400, Len Brown wrote:
> >>> Hi Andy
a very specific way, yes, this could matter.
In the grand scheme of things, this is a pretty small issue,
say, compared to the API discussion.
thanks,
Len Brown, Intel Open Source Technology Center
-Len
uest do not.
I will find out what the relative cost is on bare metal, where VMEXIT
is not an issue.
--
Len Brown, Intel Open Source Technology Center
> In particular, the library may use instructions that main() doesn't know
> exist.
And so I'll ask my question another way.
How is it okay to change the value of XCR0 during the run time of a program?
I submit that it is not, and that is a deal-killer for a request/release API.
eg. main()
On Mon, Mar 29, 2021 at 11:43 AM Len Brown wrote:
>
> On Mon, Mar 29, 2021 at 9:33 AM Thomas Gleixner wrote:
>
> > > I found the author of this passage, and he agreed to revise it to say this
> > > was targeted primarily at VMMs.
> >
> > Why would this onl
On Sat, Mar 27, 2021 at 5:58 AM Greg KH wrote:
>
> On Fri, Mar 26, 2021 at 11:39:18PM -0400, Len Brown wrote:
> > Hi Andy,
> >
> > Say a mainline links with a math library that uses AMX without the
> > knowledge of the mainline.
sorry for the confusion.
ma
maximum turbo frequency of other cores.
>
> That's the same on bare metal, right?
Yes, the hardware works exactly the same way.
thanks,
Len Brown, Intel Open Source Technology Center
INIT=1 state.
thanks,
Len Brown, Intel Open Source Technology Center
"negative power and performance implications" refers to the fact that
the processor will not enter C6 when AMX INIT=0, instead it will demote
to the next shallower C-state, eg C1E.
(this is because the C6 flow doesn't save the AMX registers)
For customers that have C6 enabled, the inability of a core to enter C6
may impact the maximum turbo frequency of other cores.
thanks,
-Len Brown
Intel Open Source Technology Center
nother thread switches in with INIT=1, there is no concept of
AMX frequency caps. (see note for 2b)
I do not see a situation where the kernel needs to issue TILERELEASE
(though a VMM likely would).
What did I miss?
thanks,
Len Brown, Intel Open Source Technology Center
ps. I will respond to your ABI thoughts on your new ABI thread.
On Fri, Mar 26, 2021 at 2:17 PM Borislav Petkov wrote:
>
> On Fri, Mar 26, 2021 at 01:53:47PM -0400, Len Brown wrote:
> > At Dave's suggestion, we had a 64 *KB* sanity check on this path.
> > Boris forced us to remove it, because we could not tell him
> > how we chose the
the threading library?
thanks,
Len Brown, Intel Open Source Technology Center
frankly, a command line option that may well break lots of userspace
> but that we fully expect Intel to recommend setting is not a good
> thing.
There is no analogy between AMX and PKRU, except the fact that they
are both features, and at one time, both were new.
I am unaware of anybody at
ul as the tweet of today.
I will do so the moment I am permitted.
I'm fine with dropping patch 22 until it can rely on the assurance of
that architectural feature.
thanks,
Len Brown, Intel Open Source Technology Center
On Thu, Mar 25, 2021 at 9:42 PM Andy Lutomirski wrote:
> Regardless of what you call AMX, AMX requires kernel enabling.
I submit, that after the generic XFD support is in place,
there is exactly 1 bit that needs to be flipped to enable
user applications to benefit from AMX.
I submit the patch
On Thu, Mar 25, 2021 at 7:10 PM Dave Hansen wrote:
>
> On 3/25/21 3:59 PM, Len Brown wrote:
> > We call AMX a "simple state feature" -- it actually requires NO KERNEL
> > ENABLING
> > above the generic state save/restore to fully support userspace AMX
> >
nd I don't know
that making it so would be an improvement.
Like the CPUID cmdline, it is precise, it is future-proof, and it is
used only in special situations.
thanks,
Len Brown, Intel Open Source Technology Center
t use it for itself.
Rather, the VMM must context switch it when it switches between guests.
(or not expose it to guests at all)
cheers,
-Len
cheers,
Len Brown, Intel Open Source Technology Center
th #NM cause) is viable.
We have the bit set in XCR0, so no state size advantage.
Still have issues with API logistics.
So we didn't see that the API adds any value, only pain,
over transparent 1st use enabling with XFD and no API.
cheers,
Len Brown, Intel Open Source Technology Center
the potential overflow at run-time,
and instead of killing the process, just push the signal onto the
regular user stack.
this might actually work, but it is sort of devious; and it would not
work in the case
where the user overflowed their regular stack already, which may be
the most (only?)
compelling reason that they allocated and declared a special
sigaltstack in the first place...
--
Len Brown, Intel Open Source Technology Center
wrote:
>
> Hi Len,
>
>
> thank you for your reply.
>
> On Thu, Mar 11, 2021 at 3:19 PM Len Brown wrote:
> >
> > Thanks for the close read, Doug.
> >
> > This field size actually varies from system to system,
> > but the reality is that the of
; +++ b/tools/power/x86/turbostat/turbostat.c
> @@ -4823,7 +4823,7 @@ int read_tcc_activation_temp()
>
> target_c = (msr >> 16) & 0xFF;
>
> - offset_c = (msr >> 24) & 0xF;
> + offset_c = (msr >> 24) & 0x3F;
>
> tcc = target_c - offset_c;
>
> --
> 2.25.1
>
--
Len Brown, Intel Open Source Technology Center
Thanks for the update, Thomas.
V1 prevented rc6 automated suspend/resume testing on all 13 of my
local machines.
V2 applied, and they are back in business.
tested-by: Len Brown
On Mon, Feb 1, 2021 at 2:25 PM Thomas Gleixner wrote:
>
> The recent change to validate the RTC turn
pace inside the hypervisor. It can expose XFD to the guests,
(and context switch it when guests switch on/off physical CPUs)
The guest sees two cases, either XFD exists or it doesn't, just like
on real hardware.
thanks,
Len Brown, Intel Open Source Technology Center
ng their existing binary.
You are right -- the feature isn't needed to enable AMX, unless somebody went to
the trouble of building a kernel with the AMX source update, but chose
to disable
AMX-specific recognition, by-default.
thanks,
Len Brown, Intel Open Source Technology Center
olatile and caller saved. The callee can assume
they are empty -- so even by virtue of being in a fork system call,
that state is already gone.
thanks,
Len Brown, Intel Open Source Technology Center
Hi Linus,
Please pull these turbostat related patches.
thanks!
Len Brown, Intel Open Source Technology Center
The following changes since commit e00b62f0b06d0ae2b844049f216807617aff0cdb:
x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to
Intel CPU family (2020-07-25 12:16:59
> -D_FILE_OFFSET_BITS=64
Applied.
thanks!
-Len
On Mon, Aug 24, 2020 at 12:09 AM Liwei Song wrote:
>
>
>
> On 8/24/20 04:54, Alexander Monakov wrote:
> > Hi,
> >
> > I am not the original submitter, but I have answers and a proper patch :)
> >
&
ostat
> will failed with "out of range" error.
>
> Thanks,
> Liwei.
>
> On 8/14/20 05:43, Len Brown wrote:
> > Huh?
> >
> > On Fri, Jul 17, 2020 at 2:09 AM Liwei Song wrote:
> >>
> >> with 32-bit rootfs, the offset may out of range w
at any time where a patch stands.
thanks!
Len Brown, Intel Open Source Technology Center
Already have this one.
thanks!
Len Brown, Intel Open Source Technology Center
Applied.
thanks!
Len Brown, Intel Open Source Technology Center
t;
> void turbostat_loop()
> {
> @@ -5735,6 +5983,7 @@ void cmdline(int argc, char **argv)
> {"hide",required_argument, 0, 'H'},//
> meh, -h taken by --help
> {"Joules", no_argument,0, 'J'},
> {"list",no_argument,0, 'l'},
> + {"Longtime",no_argument,0, 'L'},
> {"out", required_argument, 0, 'o'},
> {"quiet", no_argument,0, 'q'},
> {"show",required_argument, 0, 's'},
> @@ -5746,7 +5995,7 @@ void cmdline(int argc, char **argv)
>
> progname = argv[0];
>
> - while ((opt = getopt_long_only(argc, argv, "+C:c:Dde:hi:Jn:o:qST:v",
> + while ((opt = getopt_long_only(argc, argv, "+C:c:Dde:hi:JLn:o:qST:v",
> long_options, _index)) != -1) {
> switch (opt) {
> case 'a':
> @@ -5800,6 +6049,9 @@ void cmdline(int argc, char **argv)
> list_header_only++;
> quiet++;
> break;
> + case 'L':
> + longtime = 1;
> + break;
> case 'o':
> outf = fopen_or_die(optarg, "w");
> break;
> @@ -5864,6 +6116,8 @@ int main(int argc, char **argv)
> return 0;
> }
>
> + if (longtime)
> + msr_longtime_record();
> /*
> * if any params left, it must be a command to fork
> */
> --
> 2.17.1
>
--
Len Brown, Intel Open Source Technology Center
t_msr_fd(cpu), msr, sizeof(*msr),
> offset);
>
> if (retval != sizeof *msr)
> err(-1, "cpu%d: msr offset 0x%llx read failed", cpu,
> (unsigned long long)offset);
> --
> 2.17.1
>
--
Len Brown, Intel Open Source Technology Center
BIC(BIC_sysfs))
> - return;
> -
> if (access("/sys/devices/system/cpu/cpuidle", R_OK)) {
> fprintf(outf, "cpuidle not loaded\n");
> return;
> --
> 2.25.1
>
--
Len Brown, Intel Open Source Technology Center
g;
> > len.br...@intel.com
> > Cc: linux-kernel@vger.kernel.org; Len Brown
> > Subject: RE: [PATCH] tools/power turbostat: Make interval calculation per
> > thread to reduce jitter
> >
> > > -Original Message-
> > > From: linux-kernel-ow...@vg
Commit-ID: 835896a59b9577d0bc2131e027c37bdde5b979af
Gitweb: https://git.kernel.org/tip/835896a59b9577d0bc2131e027c37bdde5b979af
Author: Len Brown
AuthorDate: Mon, 13 May 2019 13:59:01 -0400
Committer: Thomas Gleixner
CommitDate: Thu, 23 May 2019 10:08:36 +0200
hwmon/coretemp: Cosmetic
Commit-ID: b2ce1c883df91a231f8138935167273c1767ad66
Gitweb: https://git.kernel.org/tip/b2ce1c883df91a231f8138935167273c1767ad66
Author: Len Brown
AuthorDate: Mon, 13 May 2019 13:59:00 -0400
Committer: Thomas Gleixner
CommitDate: Thu, 23 May 2019 10:08:36 +0200
thermal
Commit-ID: 2e4c54dac7b360c3820399bdf06cde9134a4495b
Gitweb: https://git.kernel.org/tip/2e4c54dac7b360c3820399bdf06cde9134a4495b
Author: Len Brown
AuthorDate: Mon, 13 May 2019 13:58:56 -0400
Committer: Thomas Gleixner
CommitDate: Thu, 23 May 2019 10:08:34 +0200
topology: Create
Commit-ID: b73ed8dc0597c11ec5064d06b9bbd4e541b6d4e7
Gitweb: https://git.kernel.org/tip/b73ed8dc0597c11ec5064d06b9bbd4e541b6d4e7
Author: Len Brown
AuthorDate: Mon, 13 May 2019 13:58:55 -0400
Committer: Thomas Gleixner
CommitDate: Thu, 23 May 2019 10:08:34 +0200
topology: Create
Commit-ID: 212bf4fdb7f9eeeb99afd97ebad677d43e7b55ac
Gitweb: https://git.kernel.org/tip/212bf4fdb7f9eeeb99afd97ebad677d43e7b55ac
Author: Len Brown
AuthorDate: Mon, 13 May 2019 13:58:49 -0400
Committer: Thomas Gleixner
CommitDate: Thu, 23 May 2019 10:08:32 +0200
x86/topology: Define
Commit-ID: 306a0de329f77537f29022c2982006f9145d782d
Gitweb: https://git.kernel.org/tip/306a0de329f77537f29022c2982006f9145d782d
Author: Len Brown
AuthorDate: Mon, 13 May 2019 13:58:48 -0400
Committer: Thomas Gleixner
CommitDate: Thu, 23 May 2019 10:08:31 +0200
x86/topology: Define
Commit-ID: 0e344d8c709fe01d882fc0fb5452bedfe5eba67a
Gitweb: https://git.kernel.org/tip/0e344d8c709fe01d882fc0fb5452bedfe5eba67a
Author: Len Brown
AuthorDate: Mon, 13 May 2019 13:58:47 -0400
Committer: Thomas Gleixner
CommitDate: Thu, 23 May 2019 10:08:31 +0200
cpu/topology: Export
Commit-ID: 14d96d6c06b5d8116b8d52c9c5530f5528ef1e61
Gitweb: https://git.kernel.org/tip/14d96d6c06b5d8116b8d52c9c5530f5528ef1e61
Author: Len Brown
AuthorDate: Mon, 13 May 2019 13:58:46 -0400
Committer: Thomas Gleixner
CommitDate: Thu, 23 May 2019 10:08:30 +0200
x86/topology: Create
Commit-ID: 7745f03eb39587dd15a1fb26e6223678b8e906d2
Gitweb: https://git.kernel.org/tip/7745f03eb39587dd15a1fb26e6223678b8e906d2
Author: Len Brown
AuthorDate: Mon, 13 May 2019 13:58:45 -0400
Committer: Thomas Gleixner
CommitDate: Thu, 23 May 2019 10:08:30 +0200
x86/topology: Add CPUID
From: Len Brown
Define topology_logical_die_id() ala
existing topology_logical_package_id()
Tested-by: Zhang Rui
Signed-off-by: Len Brown
---
arch/x86/include/asm/processor.h | 1 +
arch/x86/include/asm/topology.h | 5
arch/x86/kernel/cpu/common.c | 1 +
arch/x86/kernel
From: Len Brown
Export die_id in cpu topology, for the benefit of hardware that
has multiple-die/package.
Signed-off-by: Len Brown
Cc: linux-...@vger.kernel.org
---
Documentation/cputopology.txt | 15 ---
drivers/base/topology.c | 4
include/linux/topology.h | 3
From: Zhang Rui
Syntax only, no functional or semantic change.
Simplify how the code to discover a package is called.
Rename find_package_by_id() to rapl_find_package_domain()
Signed-off-by: Zhang Rui
Signed-off-by: Len Brown
Acked-by: Rafael J. Wysocki
Cc: linux...@vger.kernel.org
e, instead of just one.
Signed-off-by: Zhang Rui
Signed-off-by: Len Brown
---
drivers/thermal/intel/x86_pkg_temp_thermal.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/intel/x86_pkg_temp_thermal.c
b/drivers/thermal/intel/x86_pkg_temp_therm
From: Len Brown
topology_max_packages() is available to size resources to
cover all packages in the system.
But now we have multi-die/package systems, and some
resources are per-die.
Create topology_max_die_per_package(), for detecting
multi-die/package systems, and sizing any per-die
From: Len Brown
Create CPU topology sysfs attributes: "core_cpus" and "core_cpus_list"
These attributes represent all of the logical CPUs that share the
same core.
These attriutes is synonymous with the existing "thread_siblings" and
"thread_siblings_list&q
From: Len Brown
Syntax update only -- no logical or functional change.
In response to the new multi-die/package changes, update variable names
to use the more generic thermal "zone" terminology, instead of "package",
as the zones can refer to either packages or die.
Sign
uot;pkg".
Signed-off-by: Kan Liang
Signed-off-by: Len Brown
---
arch/x86/events/intel/uncore.c | 74 ++--
arch/x86/events/intel/uncore.h | 4 +-
arch/x86/events/intel/uncore_snbep.c | 4 +-
3 files changed, 41 insertions(+), 41 deletions(-)
diff --git
From: Len Brown
Syntax update only -- no logical or functional change.
In response to the new multi-die/package changes, update variable names
to use the more generic thermal "zone" terminology, instead of "package",
as the zones can refer to either packages or die.
Sign
().
There is no functional change for previous platforms.
Signed-off-by: Kan Liang
Cc: Peter Zijlstra
Signed-off-by: Len Brown
---
arch/x86/events/intel/uncore.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/x86/events/intel/uncore.c b/arch/x86
as topology_core_cpumask().
There is no functional change for previous platforms.
Name the die-scope PMU "cstate_die".
Signed-off-by: Kan Liang
Cc: Peter Zijlstra
Signed-off-by: Len Brown
---
arch/x86/events/intel/cstate.c | 14 ++
1 file changed, 10 insertions(+), 4
gned-off-by: Zhang Rui
Signed-off-by: Len Brown
Acked-by: Rafael J. Wysocki
Cc: linux...@vger.kernel.org
---
drivers/powercap/intel_rapl.c | 57 ---
1 file changed, 32 insertions(+), 25 deletions(-)
diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/i
uot;pkg".
Signed-off-by: Kan Liang
Signed-off-by: Len Brown
---
arch/x86/events/intel/rapl.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/x86/events/intel/rapl.c b/arch/x86/events/intel/rapl.c
index 6f5331271563..3992b0e65a55 100644
--- a/arc
Zijlstra
Signed-off-by: Len Brown
---
arch/x86/events/intel/rapl.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/events/intel/rapl.c b/arch/x86/events/intel/rapl.c
index 37ebf6fc5415..6f5331271563 100644
--- a/arch/x86/events/intel/rapl.c
+++ b/arch/x86
e internal variables
in response to multi-die/pkg support
I'm not aware of any outstanding feedback on this series,
functional or cosmetic.
thanks,
Len Brown, Intel Opensource Technology Center
--
The following changes since commit a13f0655503a4a89df67fdc7cac6a7810795d4b3:
Merge tag 'iom
From: Len Brown
The existing sysfs cpu/topology/core_siblings (and core_siblings_list)
attributes are documented, implemented, and used by programs to
represent set of logical CPUs sharing the same package.
This makes sense if the next topology level above a core
is always a package
From: Len Brown
topology_die_id(cpu) is a simple macro for use inside the kernel
to get the die_id associated with the given cpu.
Signed-off-by: Len Brown
---
arch/x86/include/asm/topology.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include
ackage, when present.
No change on single die/package systems.
Signed-off-by: Zhang Rui
Signed-off-by: Len Brown
Acked-by: Rafael J. Wysocki
Cc: linux...@vger.kernel.org
---
drivers/powercap/intel_rapl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/powercap/in
patch as below?
Also fine with me.
And I've replaced my rename patch with yours here too.
thanks,
Len Brown, Intel Open Source Technology Center
as below?
Fine with me!
I've replaced my patch with yours in the series.
thanks,
Len Brown, Intel Open Source Technology Center
On Tue, May 7, 2019 at 8:22 AM Peter Zijlstra wrote:
>
> On Mon, May 06, 2019 at 05:26:11PM -0400, Len Brown wrote:
> > @@ -1223,7 +1225,7 @@ static int uncore_event_cpu_online(unsigned int cpu)
> > struct intel_uncore_box *box;
> > int i, ret, pkg, t
On Tue, May 7, 2019 at 8:21 AM Peter Zijlstra wrote:
>
> On Mon, May 06, 2019 at 05:26:11PM -0400, Len Brown wrote:
> > @@ -1411,7 +1413,7 @@ static int __init intel_uncore_init(void)
> > if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
> > return -ENODEV;
&g
On Tue, May 7, 2019 at 8:15 AM Peter Zijlstra wrote:
>
> On Mon, May 06, 2019 at 05:26:05PM -0400, Len Brown wrote:
> > From: Zhang Rui
> >
> > RAPL "package" domains are actually implemented in hardware per-die.
> > Thus, the new multi-die/package syste
From: Len Brown
Some new systems have multiple software-visible die within each package.
Update Linux parsing of the Intel CPUID "Extended Topology Leaf"
to handle either CPUID.B, or the new CPUID.1F.
Add cpuinfo_x86.die_id and cpuinfo_x86.max_dies to store the result.
die_id will b
From: Len Brown
topology_max_packages() is available to size resources to
cover all packages in the system.
But now we have multi-die/package systems, and some
resources are per-die.
Create topology_max_die_per_package(), for detecting
multi-die/package systems, and sizing any per-die
From: Len Brown
Define topology_logical_die_id() ala
existing topology_logical_package_id()
Tested-by: Zhang Rui
Signed-off-by: Len Brown
---
arch/x86/include/asm/processor.h | 1 +
arch/x86/include/asm/topology.h | 5
arch/x86/kernel/cpu/common.c | 1 +
arch/x86/kernel
From: Len Brown
Create CPU topology sysfs attributes: "core_cpus" and "core_cpus_list"
These attributes represent all of the logical CPUs that share the
same core.
These attriutes is synonymous with the existing "thread_siblings" and
"thread_siblings_list&q
From: Len Brown
Syntax only, no functional or semantic change.
This routine matches packages, not die, so name it thus.
Signed-off-by: Len Brown
---
arch/x86/kernel/smpboot.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel
From: Zhang Rui
Syntax only, no functional or semantic change.
Simplify how the code to discover a package is called.
Rename find_package_by_id() to rapl_find_package_domain()
Signed-off-by: Zhang Rui
Signed-off-by: Len Brown
Acked-by: Rafael J. Wysocki
Cc: linux...@vger.kernel.org
e, instead of just one.
Signed-off-by: Zhang Rui
Signed-off-by: Len Brown
---
drivers/thermal/intel/x86_pkg_temp_thermal.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/intel/x86_pkg_temp_thermal.c
b/drivers/thermal/intel/x86_pkg_temp_therm
From: Len Brown
Syntax update only -- no logical or functional change.
In response to the new multi-die/package changes, update variable names
to use the more generic thermal "zone" terminology, instead of "package",
as the zones can refer to either packages or die.
Sign
as topology_core_cpumask().
There is no functional change for previous platforms.
Name the die-scope PMU "cstate_die".
Signed-off-by: Kan Liang
Cc: Peter Zijlstra
Signed-off-by: Len Brown
---
arch/x86/events/intel/cstate.c | 14 ++
1 file changed, 10 insertions(+), 4
gned-off-by: Zhang Rui
Signed-off-by: Len Brown
Acked-by: Rafael J. Wysocki
Cc: linux...@vger.kernel.org
---
drivers/powercap/intel_rapl.c | 57 ---
1 file changed, 32 insertions(+), 25 deletions(-)
diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/i
1 - 100 of 2316 matches
Mail list logo
