On 5/25/2019 4:48 AM, Ingo Molnar wrote:
* kan.li...@linux.intel.com wrote:
@@ -57,6 +57,11 @@ static unsigned int pt_regs_offset[PERF_REG_X86_MAX] = {
#endif
};
+u64 non_generic_regs_mask(void)
+{
+ return (~((1ULL << PERF_REG_X86_XMM0) - 1));
+}
+
u64
On 5/24/2019 9:03 AM, Vince Weaver wrote:
I've run the fuzzer overnight with both patches applied and have not seen
any issues.
Thanks a lot for the test.
Kan
On 5/23/2019 12:30 PM, Vince Weaver wrote:
On Wed, 22 May 2019, Liang, Kan wrote:
XMM registers can only collected by hardware PEBS events. We should disable it
for all software/probe events.
Could you please try the patch as below?
I tested the patch (it was whitespace damaged for some
On 5/22/2019 6:50 PM, Jiri Olsa wrote:
On Wed, May 22, 2019 at 05:54:58PM -0400, Liang, Kan wrote:
SNIP
[ 9680.197779] RSP: 002b:7fff595603a8 EFLAGS: 0206 ORIG_RAX:
ff13
[ 9680.205489] RAX: 4985 RBX: 000c RCX: 000365ca
[ 9680.212748] RDX
On 5/22/2019 12:08 PM, Vince Weaver wrote:
The perf fuzzer caused my skylake machine to crash hard with the trace at
the end here. (this is with current git)
It appears to be happening in new code introduced by:
commit 878068ea270ea82767ff1d26c91583263c81fba0
Author: Kan Liang
Date:
On 5/15/2019 2:49 AM, Ravi Bangoria wrote:
On 5/15/19 1:49 AM, kan.li...@linux.intel.com wrote:
From: Kan Liang
The available registers for --int-regs and --user-regs may be different,
e.g. XMM registers.
Split parse_regs into two dedicated functions for --int-regs and
--user-regs
On 5/14/2019 2:19 PM, Arnaldo Carvalho de Melo wrote:
Em Tue, May 14, 2019 at 07:39:12AM -0700, kan.li...@linux.intel.com escreveu:
From: Kan Liang
Some non general purpose registers, e.g. XMM, can be collected on some
platforms, e.g. X86 Icelake.
Add a weak function
On 5/14/2019 8:59 AM, Arnaldo Carvalho de Melo wrote:
Em Mon, May 13, 2019 at 05:29:30PM -0400, Liang, Kan escreveu:
Hi Arnaldo,
Could you please apply this fix?
Sure, please next time specify which arch this should be tested on, as I
tried it here on a skylake notebook (lenovo t480s
Hi Arnaldo,
Could you please apply this fix?
Thanks,
Kan
On 5/7/2019 9:16 AM, kan.li...@linux.intel.com wrote:
From: Kan Liang
Perf cannot parse UPI events.
#perf stat -e UPI_DATA_BANDWIDTH_TX
event syntax error: 'UPI_DATA_BANDWIDTH_TX'
\___ parser error
On 5/13/2019 2:37 PM, Arnaldo Carvalho de Melo wrote:
Em Mon, May 13, 2019 at 01:37:16PM -0400, Arnaldo Carvalho de Melo escreveu:
Em Mon, May 06, 2019 at 07:19:24AM -0700, kan.li...@linux.intel.com escreveu:
From: Andi Kleen
Icelake and later platforms support collecting XMM registers
On 5/6/2019 5:26 PM, Len Brown wrote:
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 "pmuid" terminology, instead of "pkgid",
as the pmu can refer to either packages or
On 5/6/2019 5:26 PM, Len Brown wrote:
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 "box" terminology, instead of "pkg",
as the boxes can refer to either packages or
On 4/30/2019 5:08 AM, Peter Zijlstra wrote:
On Mon, Apr 29, 2019 at 04:02:33PM -0700, Ian Rogers wrote:
This is very interesting. How does the code handle cgroup hierarchies?
For example, if we have:
cgroup0 is the cgroup root
cgroup1 whose parent is cgroup0
cgroup2 whose parent is cgroup1
On 4/30/2019 5:03 AM, Peter Zijlstra wrote:
On Mon, Apr 29, 2019 at 07:44:04AM -0700, kan.li...@linux.intel.com wrote:
Add unique cgrp_id for each cgroup, which is composed by CPU ID and css
subsys-unique ID.
*WHY* ?! that doesn't make any kind of sense.. In fact you mostly then
use the
On 4/30/2019 4:56 AM, Peter Zijlstra wrote:
On Mon, Apr 29, 2019 at 07:44:02AM -0700, kan.li...@linux.intel.com wrote:
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index e47ef76..039e2f2 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@
On 4/29/2019 11:12 AM, Mark Rutland wrote:
On Mon, Apr 29, 2019 at 07:44:03AM -0700, kan.li...@linux.intel.com wrote:
From: Kan Liang
A fast path will be introduced in the following patches to speed up the
cgroup events sched in, which only needs a simpler filter_match().
Add
On 4/29/2019 11:04 AM, Mark Rutland wrote:
On Mon, Apr 29, 2019 at 07:44:02AM -0700, kan.li...@linux.intel.com wrote:
From: Kan Liang
When counting system-wide events and cgroup events simultaneously, the
value of system-wide events are miscounting. For example,
perf stat -e
On 4/25/2019 1:47 PM, Ingo Molnar wrote:
* Liang, Kan wrote:
On 4/25/2019 2:39 AM, Ingo Molnar wrote:
* kan.li...@linux.intel.com wrote:
+static void smi_env_check(void)
+{
+ char *name;
+ size_t len;
+
+ if (sysfs__read_str(CPUIDLE_CUR_DRV
On 4/25/2019 2:39 AM, Ingo Molnar wrote:
* kan.li...@linux.intel.com wrote:
+static void smi_env_check(void)
+{
+ char *name;
+ size_t len;
+
+ if (sysfs__read_str(CPUIDLE_CUR_DRV, , )) {
+ pr_warning("Failed to check cstate status.\n");
What a
Hi Arnaldo and Jirka,
Have you got a chance to review this patch series?
This series is user space tool support for Icelake and Tremont.
Thanks,
Kan
On 4/16/2019 11:24 AM, kan.li...@linux.intel.com wrote:
From: Andi Kleen
Icelake and later platforms support collecting XMM registers with
Hi Peter,
Have you got a chance to take a look at the series for Snow Ridge server?
Here is the link for the document.
https://cdrdv2.intel.com/v1/dl/getContent/611319
Thanks,
Kan
On 4/15/2019 2:41 PM, kan.li...@linux.intel.com wrote:
From: Kan Liang
The uncore subsystem on Snow Ridge is
On 4/11/2019 9:33 AM, Peter Zijlstra wrote:
On Thu, Apr 11, 2019 at 09:30:10AM -0400, Liang, Kan wrote:
I changed that like so:
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3508,7 +3508,7 @@ tnt_get_event_constraints(struct cpu_hw_
*/
if (event
On 4/11/2019 5:06 AM, Peter Zijlstra wrote:
On Wed, Apr 10, 2019 at 11:57:09AM -0700, kan.li...@linux.intel.com wrote:
+static struct event_constraint *
+tnt_get_event_constraints(struct cpu_hw_events *cpuc, int idx,
+ struct perf_event *event)
That 'tnt' still
On 4/11/2019 5:00 AM, Peter Zijlstra wrote:
On Wed, Apr 10, 2019 at 09:47:20PM +0200, Peter Zijlstra wrote:
Sure, those are actually forced 0 with the existing thing.
I'll go fold smething like back in. Thanks!
@@ -3472,7 +3475,7 @@ icl_get_event_constraints(struct cpu_hw_events *cpuc,
On 4/8/2019 11:45 AM, Liang, Kan wrote:
On 4/8/2019 11:06 AM, Peter Zijlstra wrote:
On Tue, Apr 02, 2019 at 12:45:05PM -0700, kan.li...@linux.intel.com
wrote:
+static struct event_constraint *
+icl_get_event_constraints(struct cpu_hw_events *cpuc, int idx,
+ struct perf_event
On 4/10/2019 3:51 AM, Peter Zijlstra wrote:
On Tue, Apr 09, 2019 at 06:10:00PM -0700, kan.li...@linux.intel.com wrote:
The generic purpose counter 0 and fixed counter 0 have less skid.
Force :ppp events on generic purpose counter 0.
Force instruction:ppp always on fixed counter 0.
On 4/10/2019 3:41 AM, Peter Zijlstra wrote:
On Tue, Apr 09, 2019 at 06:09:59PM -0700, kan.li...@linux.intel.com wrote:
From: Kan Liang
Fixed counters can also generate adaptive PEBS record, if the
corresponding bit in IA32_FIXED_CTR_CTRL is set.
Otherwise, only basic record is generated.
On 4/8/2019 12:06 PM, Liang, Kan wrote:
@@ -1875,7 +1868,7 @@ static void intel_pmu_drain_pebs_nhm(str
counts[bit]++;
}
- for (bit = 0; bit < size; bit++) {
+ for_each_set_bit(bit, (unsigned long *), size) {
if ((counts[bit] == 0) && (erro
@@ -963,40 +963,42 @@ static u64 pebs_update_adaptive_cfg(stru
u64 pebs_data_cfg = 0;
bool gprs, tsx_weight;
- if ((sample_type & ~(PERF_SAMPLE_IP|PERF_SAMPLE_TIME)) ||
- attr->precise_ip < 2) {
+ if (!(sample_type & ~(PERF_SAMPLE_IP|PERF_SAMPLE_TIME)) &&
+
On 4/8/2019 11:41 AM, Peter Zijlstra wrote:
I currently have something like the below on top, is that correct?
Yes, it's correct.
If so, I'll fold it back in.
Thanks. It's really appreciated.
Kan
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -563,16 +563,17 @@ int
On 4/8/2019 11:06 AM, Peter Zijlstra wrote:
On Tue, Apr 02, 2019 at 12:45:05PM -0700, kan.li...@linux.intel.com wrote:
+static struct event_constraint *
+icl_get_event_constraints(struct cpu_hw_events *cpuc, int idx,
+ struct perf_event *event)
+{
+ /*
+
On 4/1/2019 5:11 PM, Stephane Eranian wrote:
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index e2b1447192a8..9378c6b2128f 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -560,6 +560,16 @@ int x86_pmu_hw_config(struct perf_event *event)
On 4/1/2019 3:18 PM, Stephane Eranian wrote:
On Tue, Mar 26, 2019 at 9:11 AM wrote:
From: Kan Liang
Starting from Icelake, XMM registers can be collected in PEBS record.
But current code only output the pt_regs.
Add a new struct x86_perf_regs for both pt_regs and xmm_regs.
XMM registers
Hi Peter and Thomas,
Have you got a chance to review this series?
Any comments are very appreciated.
Thanks,
Kan
On 3/26/2019 12:08 PM, kan.li...@linux.intel.com wrote:
From: Kan Liang
The patch series intends to add Icelake support for Linux perf.
PATCH 1-18: Kernel patches to support
On 3/18/2019 4:53 AM, Jiri Olsa wrote:
On Fri, Mar 15, 2019 at 11:00:14AM -0700, kan.li...@linux.intel.com wrote:
From: Kan Liang
Perf fails to parse uncore event alias, for example:
#perf stat -e unc_m_clockticks -a --no-merge sleep 1
event syntax error: 'unc_m_clockticks'
On 3/26/2019 6:24 PM, Andi Kleen wrote:
+ for (at = base; at < top; at += cpuc->pebs_record_size) {
+ u64 pebs_status;
+
+ pebs_status = get_pebs_status(at) & cpuc->pebs_enabled;
+ pebs_status &= mask;
+
+ for_each_set_bit(bit,
On 3/26/2019 9:47 AM, Thomas Gleixner wrote:
On Tue, 26 Mar 2019, Liang, Kan wrote:
On 3/25/2019 8:11 PM, Thomas Gleixner wrote:
-#define REG_RESERVED (~((1ULL << PERF_REG_X86_MAX) - 1ULL))
+#define REG_RESERVED 0
What's the point of having this around?
I once thought it may b
On 3/25/2019 8:11 PM, Thomas Gleixner wrote:
On Fri, 22 Mar 2019, kan.li...@linux.intel.com wrote:
+ PERF_REG_X86_XMM15 = 62,
+
+ /* All registers include the XMMX registers */
+ PERF_REG_X86_MAX = PERF_REG_X86_XMM15 + 2,
Ergo: PERF_REG_X86_MAX == 64
-#define
On 3/23/2019 5:56 AM, Peter Zijlstra wrote:
On Fri, Mar 22, 2019 at 10:22:50AM -0700, Andi Kleen wrote:
diff --git a/arch/x86/include/uapi/asm/perf_regs.h
b/arch/x86/include/uapi/asm/perf_regs.h
index f3329cabce5c..b33995313d17 100644
--- a/arch/x86/include/uapi/asm/perf_regs.h
+++
On 3/21/2019 5:20 PM, Peter Zijlstra wrote:
On Thu, Mar 21, 2019 at 01:56:44PM -0700, kan.li...@linux.intel.com wrote:
@@ -933,6 +1001,34 @@ pebs_update_state(bool needed_cb, struct cpu_hw_events
*cpuc, struct pmu *pmu)
update = true;
}
+ /*
+* The PEBS
On 3/19/2019 8:08 PM, Stephane Eranian wrote:
On Mon, Mar 18, 2019 at 2:44 PM wrote:
From: Kan Liang
Add Icelake core PMU perf code, including constraint tables and the main
enable code.
Icelake expanded the generic counters to always 8 even with HT on, but a
range of events cannot be
On 3/19/2019 10:47 AM, Peter Zijlstra wrote:
@@ -933,6 +998,19 @@ pebs_update_state(bool needed_cb, struct cpu_hw_events
*cpuc, struct pmu *pmu)
update = true;
}
+ if (x86_pmu.intel_cap.pebs_baseline && add) {
+ u64 pebs_data_cfg;
+
+
platforms.
Thanks,
Kan
On 2/20/2019 9:36 AM, Liang, Kan wrote:
On 2/20/2019 6:12 AM, Peter Zijlstra wrote:
On Tue, Feb 19, 2019 at 12:00:02PM -0800, kan.li...@linux.intel.com
wrote:
It's very useful to abstract several common topology related codes for
these modules to reduce the code
On 3/1/2019 6:42 AM, Jiri Olsa wrote:
hi,
I'm getting zero counts for energy-cores event on broadwell-x
server (model 0x4f)
I checked intel_rapl powercap driver and it won't export the
counter if it rdmsr returns zero on it
the SDM also says the rdmsr returns zero for some models
I made
On 2/20/2019 6:12 AM, Peter Zijlstra wrote:
On Tue, Feb 19, 2019 at 12:00:02PM -0800, kan.li...@linux.intel.com wrote:
It's very useful to abstract several common topology related codes for
these modules to reduce the code redundancy.
3 files changed, 96 insertions(+), 1 deletion(-)
On 2/19/2019 1:43 PM, Brown, Len wrote:
Thanks for the comments, Kan,
diff --git a/Documentation/cputopology.txt
b/Documentation/cputopology.txt index 287213b4517b..7dd2ae3df233
100644
--- a/Documentation/cputopology.txt
+++ b/Documentation/cputopology.txt
@@ -56,6 +56,16 @@
On 2/18/2019 10:40 PM, Len Brown wrote:
From: Len Brown
like core_siblings, except it shows which die are in the same package.
This is needed for lscpu(1) to correctly display die topology.
Signed-off-by: Len Brown
Cc: linux-...@vger.kernel.org
Signed-off-by: Len Brown
---
On 2/18/2019 10:40 PM, Len Brown wrote:
From: Len Brown
Some new systems have multiple software-visible die within each package.
The new CPUID.1F leaf can enumerate this multi-die/package topology.
CPUID.1F a super-set of the CPUID.B "Extended Toplogy Leaf",
and a common updated routine
On 2/18/2019 9:19 AM, Steven Price wrote:
On 18/02/2019 11:31, Peter Zijlstra wrote:
On Fri, Feb 15, 2019 at 05:02:24PM +, Steven Price wrote:
From: James Morse
Exposing the pud/pgd levels of the page tables to walk_page_range() means
we may come across the exotic large mappings that
On 2/8/2019 5:39 AM, Thomas Gleixner wrote:
On Thu, 31 Jan 2019, Liang, Kan wrote:
+u64 perf_get_page_size(u64 virt)
+{
+ unsigned long flags;
+ unsigned int level;
+ pte_t *pte;
+
+ if (!virt)
+ return 0;
+
+ /*
+* Interrupts are disabled
On 2/4/2019 5:54 AM, Peter Zijlstra wrote:
On Fri, Feb 01, 2019 at 11:16:51AM -0500, Liang, Kan wrote:
if (p4d_large(*p4d)) {
This one looks like x86 specific?
if (pud_large(*pud)) {
if (pmd_large(*pmd)) {
Kirill did indeed note that p*_large() isn't
On 2/4/2019 2:43 PM, Borislav Petkov wrote:
On Mon, Feb 04, 2019 at 01:57:49PM -0500, Liang, Kan wrote:
You mean a given microcode revision X applying to multiple stepping,
right?
Yes, the range thing. You specify a range of steppings:
kabylake mobile with steppings 9-12
kabylake desktop
On 2/4/2019 1:15 PM, Borislav Petkov wrote:
On Mon, Feb 04, 2019 at 11:55:27AM -0500, Liang, Kan wrote:
We cannot apply X86_STEPPING_ANY to ignore the stepping. There will be
problems for 0-8 stepping for KABYLAKE_MOBILE.
So why are we even doing this new "inte
On 2/4/2019 11:23 AM, Peter Zijlstra wrote:
On Mon, Feb 04, 2019 at 10:57:32AM -0500, Liang, Kan wrote:
On 2/4/2019 10:44 AM, Peter Zijlstra wrote:
On Mon, Feb 04, 2019 at 04:38:27PM +0100, Peter Zijlstra wrote:
+static const struct x86_cpu_desc isolation_ucodes
On 2/4/2019 11:04 AM, Borislav Petkov wrote:
On Mon, Feb 04, 2019 at 10:57:32AM -0500, Liang, Kan wrote:
On 2/4/2019 10:44 AM, Peter Zijlstra wrote:
On Mon, Feb 04, 2019 at 04:38:27PM +0100, Peter Zijlstra wrote:
+static const struct x86_cpu_desc isolation_ucodes
On 2/4/2019 11:15 AM, Peter Zijlstra wrote:
On Mon, Feb 04, 2019 at 10:43:41AM -0500, Liang, Kan wrote:
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -1628,6 +1628,7 @@ void __init intel_ds_init(void)
x86_pmu.bts = boot_cpu_has(X86_FEATURE_BTS
On 2/4/2019 11:10 AM, Peter Zijlstra wrote:
On Mon, Jan 21, 2019 at 01:42:28PM -0800, kan.li...@linux.intel.com wrote:
+ INTEL_CPU_DESC(INTEL_FAM6_CANNONLAKE_MOBILE, 3, 0x),
Funny that, CNL doesn't have any perf support at all yet.. Maybe do that
patch first or delay this
On 2/4/2019 10:44 AM, Peter Zijlstra wrote:
On Mon, Feb 04, 2019 at 04:38:27PM +0100, Peter Zijlstra wrote:
+static const struct x86_cpu_desc isolation_ucodes[] = {
+ INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 9, 0x004e),
+ INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE,
On 2/4/2019 10:38 AM, Peter Zijlstra wrote:
This then? That's nearly what you had; except a lot less noisy.
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "../perf_event.h"
@@ -3206,16
On 2/4/2019 10:17 AM, Peter Zijlstra wrote:
On Mon, Feb 04, 2019 at 04:06:23PM +0100, Peter Zijlstra wrote:
On Mon, Jan 21, 2019 at 01:42:28PM -0800, kan.li...@linux.intel.com wrote:
So what's wrong with the below?
Installing a quirk for
(typing hard..)
but what I was going to say is
Hi all,
Ping. Any comments on this series?
Thanks,
Kan
On 1/21/2019 4:42 PM, kan.li...@linux.intel.com wrote:
From: Kan Liang
For bug workarounds or checks, it is useful to check for specific
microcode revisions.
Add a new generic function to match the CPU with stepping.
Add the other
On 2/1/2019 7:43 AM, Peter Zijlstra wrote:
On Fri, Feb 01, 2019 at 01:36:00PM +0300, Kirill A. Shutemov wrote:
On Fri, Feb 01, 2019 at 11:03:58AM +0100, Peter Zijlstra wrote:
Will just mentioned a lovely feature where some archs have multi entry
large pages.
Possible something like:
On 2/1/2019 4:22 AM, Peter Zijlstra wrote:
On Thu, Jan 31, 2019 at 12:27:54PM -0800, kan.li...@linux.intel.com wrote:
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 374a197..229a73b 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -2578,3 +2578,34 @@
On 1/31/2019 7:37 AM, Peter Zijlstra wrote:
On Wed, Jan 30, 2019 at 06:23:42AM -0800, kan.li...@linux.intel.com wrote:
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 374a197..03bf45d 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -2578,3 +2578,45 @@
On 1/28/2019 10:09 AM, Jiri Olsa wrote:
On Wed, Jan 23, 2019 at 07:15:23AM -0800, kan.li...@linux.intel.com wrote:
From: Kan Liang
Now, "--phys-data" is the only option which impacts the output format
and sort order. A simple "if else" is enough to handle the option.
But there will be more
On 1/25/2019 5:24 PM, Song Liu wrote:
I also noticed that uncore_pci_probe() returns at
if (atomic_inc_return(>activeboxes) > 1)
return 0;
for bus 1-7. So we only probed bus 0 (socket 0). Is this expected behavior?
We probed all, but only need to register PMU
On 1/25/2019 3:16 PM, Song Liu wrote:
Thanks Kan!
On Jan 25, 2019, at 12:08 PM, Liang, Kan wrote:
On 1/25/2019 1:54 PM, Song Liu wrote:
Hi,
We are debugging an issue that skx_pci_uncores cannot be registered on
8-socket system with Xeon Platinum 8176 CPUs. After poking around
On 1/25/2019 1:54 PM, Song Liu wrote:
Hi,
We are debugging an issue that skx_pci_uncores cannot be registered on
8-socket system with Xeon Platinum 8176 CPUs. After poking around for a
while, I found it is caused by snbep_pci2phy_map_init() couldn't find
a unbox_dev:
ubox_dev =
On 1/22/2019 12:11 PM, Andi Kleen wrote:
+ PERF_OUTPUT_CODE_PAGE_SIZE = 1UL << 32,
That won't work on 32bit. You need 1ULL
Also might want to audit that noone puts these flags into
an int.
I checked the codes, and there is no one puts the flags into an int.
I will use ULL in V2.
On 1/16/2019 8:14 AM, Borislav Petkov wrote:
+static __init void intel_isolation_quirk(void)
+{
+ x86_pmu.check_microcode = intel_check_isolation;
+ intel_check_isolation();
+}
+
static const struct { int id; char *name; } intel_arch_events_map[]
__initconst = {
{
On 1/8/2019 1:13 AM, Wei Wang wrote:
On 01/07/2019 10:22 PM, Liang, Kan wrote:
Thanks for sharing. I understand the point of maintaining those
models at one place,
but this factor-out doesn't seem very elegant to me, like below
__intel_pmu_init (int model, struct x86_pmu *x86_pmu
On 1/5/2019 5:09 AM, Wei Wang wrote:
On 01/04/2019 11:57 PM, Liang, Kan wrote:
On 1/4/2019 4:58 AM, Wei Wang wrote:
On 01/03/2019 12:33 AM, Liang, Kan wrote:
On 12/26/2018 4:25 AM, Wei Wang wrote:
+
+ /*
+ * It could be possible that people have vcpus of old model
run
On 1/4/2019 4:58 AM, Wei Wang wrote:
On 01/03/2019 12:33 AM, Liang, Kan wrote:
On 12/26/2018 4:25 AM, Wei Wang wrote:
+
+ /*
+ * It could be possible that people have vcpus of old model run on
+ * physcal cpus of newer model, for example a BDW guest on a SKX
+ * machine
On 12/26/2018 4:25 AM, Wei Wang wrote:
+
+ /*
+* It could be possible that people have vcpus of old model run on
+* physcal cpus of newer model, for example a BDW guest on a SKX
+* machine (but not possible to be the other way around).
+* The BDW guest
On 11/27/2018 8:25 PM, Stephane Eranian wrote:
On Tue, Nov 27, 2018 at 3:36 PM Andi Kleen wrote:
It does seem that FREEZE_PERFMON_ON_PMI (misnamed as it is) is of
rather limited use (or even negative, in our case) to a counter that's
already restricted to ring 3.
It's much faster. The
On 11/27/2018 8:25 PM, Stephane Eranian wrote:
On Tue, Nov 27, 2018 at 3:36 PM Andi Kleen wrote:
It does seem that FREEZE_PERFMON_ON_PMI (misnamed as it is) is of
rather limited use (or even negative, in our case) to a counter that's
already restricted to ring 3.
It's much faster. The
On 11/15/2018 9:14 PM, Arnaldo Carvalho de Melo wrote:
Em Thu, Nov 15, 2018 at 04:01:46PM -0500, Liang, Kan escreveu:
On 11/15/2018 3:44 PM, Jiri Olsa wrote:
On Wed, Nov 14, 2018 at 01:24:15PM -0800, kan.li...@linux.intel.com wrote:
From: Kan Liang
Perf tools cannot find the proper
On 11/15/2018 9:14 PM, Arnaldo Carvalho de Melo wrote:
Em Thu, Nov 15, 2018 at 04:01:46PM -0500, Liang, Kan escreveu:
On 11/15/2018 3:44 PM, Jiri Olsa wrote:
On Wed, Nov 14, 2018 at 01:24:15PM -0800, kan.li...@linux.intel.com wrote:
From: Kan Liang
Perf tools cannot find the proper
On 11/16/2018 11:12 AM, Sasha Levin wrote:
On Fri, Nov 16, 2018 at 05:19:45AM -0800, kan.li...@linux.intel.com wrote:
From: Kan Liang
The client IMC bandwidth events return very huge result.
perf stat -e uncore_imc/data_reads/ -e uncore_imc/data_writes/ -I
1 -a
10.000117222 34,788.76
On 11/16/2018 11:12 AM, Sasha Levin wrote:
On Fri, Nov 16, 2018 at 05:19:45AM -0800, kan.li...@linux.intel.com wrote:
From: Kan Liang
The client IMC bandwidth events return very huge result.
perf stat -e uncore_imc/data_reads/ -e uncore_imc/data_writes/ -I
1 -a
10.000117222 34,788.76
On 11/15/2018 3:44 PM, Jiri Olsa wrote:
On Wed, Nov 14, 2018 at 01:24:15PM -0800, kan.li...@linux.intel.com wrote:
From: Kan Liang
Perf tools cannot find the proper event list for Cascadelake server.
Because Cascadelake server and Skylake server have the same CPU model
number, which are
On 11/15/2018 3:44 PM, Jiri Olsa wrote:
On Wed, Nov 14, 2018 at 01:24:15PM -0800, kan.li...@linux.intel.com wrote:
From: Kan Liang
Perf tools cannot find the proper event list for Cascadelake server.
Because Cascadelake server and Skylake server have the same CPU model
number, which are
+ /*
+* Full CPUID format is required to identify a platform.
+* Error out if the cpuid string is incomplete.
+*/
+ if (full_mapcpuid && !full_cpuid) {
+ pr_info("Invalid CPUID %s. Full CPUID is required, "
+
+ /*
+* Full CPUID format is required to identify a platform.
+* Error out if the cpuid string is incomplete.
+*/
+ if (full_mapcpuid && !full_cpuid) {
+ pr_info("Invalid CPUID %s. Full CPUID is required, "
+
On 11/15/2018 9:26 AM, Liang, Kan wrote:
On 11/15/2018 8:53 AM, Jiri Olsa wrote:
On Wed, Nov 14, 2018 at 01:24:15PM -0800, kan.li...@linux.intel.com
wrote:
SNIP
diff --git a/tools/perf/arch/x86/util/header.c
b/tools/perf/arch/x86/util/header.c
index fb0d71afee8b..b428a4b00bf7 100644
On 11/15/2018 9:26 AM, Liang, Kan wrote:
On 11/15/2018 8:53 AM, Jiri Olsa wrote:
On Wed, Nov 14, 2018 at 01:24:15PM -0800, kan.li...@linux.intel.com
wrote:
SNIP
diff --git a/tools/perf/arch/x86/util/header.c
b/tools/perf/arch/x86/util/header.c
index fb0d71afee8b..b428a4b00bf7 100644
On 11/15/2018 8:53 AM, Jiri Olsa wrote:
On Wed, Nov 14, 2018 at 01:24:15PM -0800, kan.li...@linux.intel.com wrote:
SNIP
diff --git a/tools/perf/arch/x86/util/header.c
b/tools/perf/arch/x86/util/header.c
index fb0d71afee8b..b428a4b00bf7 100644
--- a/tools/perf/arch/x86/util/header.c
+++
On 11/15/2018 8:53 AM, Jiri Olsa wrote:
On Wed, Nov 14, 2018 at 01:24:15PM -0800, kan.li...@linux.intel.com wrote:
SNIP
diff --git a/tools/perf/arch/x86/util/header.c
b/tools/perf/arch/x86/util/header.c
index fb0d71afee8b..b428a4b00bf7 100644
--- a/tools/perf/arch/x86/util/header.c
+++
Hi All,
Ping.
Any comments for the series.
Thanks,
Kan
On 10/19/2018 1:04 PM, kan.li...@linux.intel.com wrote:
From: Kan Liang
KabyLake and CoffeeLake has the same client uncore events as SkyLake.
Add the PCI IDs for KabyLake Y, U, S processor line and CoffeeLake U,
H, S processor line.
Hi All,
Ping.
Any comments for the series.
Thanks,
Kan
On 10/19/2018 1:04 PM, kan.li...@linux.intel.com wrote:
From: Kan Liang
KabyLake and CoffeeLake has the same client uncore events as SkyLake.
Add the PCI IDs for KabyLake Y, U, S processor line and CoffeeLake U,
H, S processor line.
On 11/6/2018 10:00 AM, Stephane Eranian wrote:
/*
* mmap 1 page at the location of the unmap page (should reuse virtual space)
* This creates a continuous region built from two mmaps and
potentially two different sources
* especially with jitted runtimes
*/
The two mmaps are both anon. As my
On 11/6/2018 10:00 AM, Stephane Eranian wrote:
/*
* mmap 1 page at the location of the unmap page (should reuse virtual space)
* This creates a continuous region built from two mmaps and
potentially two different sources
* especially with jitted runtimes
*/
The two mmaps are both anon. As my
NONYMOUS|MAP_PRIVATE, -1, 0);
printf("addr2=%p\n", addr2);
if (addr2 == (void *)MAP_FAILED)
err(1, "mmap 2 failed");
if (addr2 != (addr1 + pgsz))
errx(1, "wrong mmap2 address");
sleep(1);
return 0;
}
On Thu, Nov 1, 2018 at 7:10 AM Liang, Kan wrote:
On 10/24/2018
NONYMOUS|MAP_PRIVATE, -1, 0);
printf("addr2=%p\n", addr2);
if (addr2 == (void *)MAP_FAILED)
err(1, "mmap 2 failed");
if (addr2 != (addr1 + pgsz))
errx(1, "wrong mmap2 address");
sleep(1);
return 0;
}
On Thu, Nov 1, 2018 at 7:10 AM Liang, Kan wrote:
On 10/24/2018
On 10/24/2018 3:30 PM, Stephane Eranian wrote:
The need for this new record type extends beyond physical address conversions
and PEBS. A long while ago, someone reported issues with symbolization related
to perf lacking munmap tracking. It had to do with vma merging. I think the
sequence of
On 10/24/2018 3:30 PM, Stephane Eranian wrote:
The need for this new record type extends beyond physical address conversions
and PEBS. A long while ago, someone reported issues with symbolization related
to perf lacking munmap tracking. It had to do with vma merging. I think the
sequence of
On 10/31/2018 9:21 AM, Arnaldo Carvalho de Melo wrote:
Em Tue, Oct 30, 2018 at 10:54:16PM -0700, David Miller escreveu:
This goes back to by-hand parsing of the proc mmap file, and removes
the timeout.
In my measurements this makes the parsing about twice as fast.
Profiling thread
On 10/31/2018 9:21 AM, Arnaldo Carvalho de Melo wrote:
Em Tue, Oct 30, 2018 at 10:54:16PM -0700, David Miller escreveu:
This goes back to by-hand parsing of the proc mmap file, and removes
the timeout.
In my measurements this makes the parsing about twice as fast.
Profiling thread
On 10/29/2018 6:42 PM, David Miller wrote:
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 18:32:40 -0400
- struct annotation_options *annotation_options
__maybe_unused)
+ struct annotation_options *annotation_options __ma
On 10/29/2018 6:42 PM, David Miller wrote:
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 18:32:40 -0400
- struct annotation_options *annotation_options
__maybe_unused)
+ struct annotation_options *annotation_options __ma
201 - 300 of 1326 matches
Mail list logo
