On 9/20/2018 9:07 PM, Masayoshi Mizuma wrote:
From: Masayoshi Mizuma
Physical package id 0 is not always exists. We should use
boot_cpu_data.logical_proc_id directly as the pkg id here.
Signed-off-by: Masayoshi Mizuma
Reviewed-by: Kan Liang
Thanks,
Kan
---
On 9/21/2018 10:14 AM, Peter Zijlstra wrote:
On Fri, Sep 21, 2018 at 07:07:06AM -0700, kan.li...@linux.intel.com wrote:
From: Kan Liang
The counters on M3UPI Link 0 and Link 3 don't count. Writing 0 to
these counters may causes system crash on some machines.
The PCI BDF addresses of M3UPI
On 8/6/2018 2:20 PM, Peter Zijlstra wrote:
On Mon, Aug 06, 2018 at 10:23:41AM -0700, kan.li...@linux.intel.com wrote:
+ if (++loops > 100) {
+ static bool warned;
+
+ if (!warned) {
+ WARN(1, "perfevents: irq loop stuck!\n");
+
On 8/6/2018 2:35 PM, Peter Zijlstra wrote:
On Mon, Aug 06, 2018 at 10:23:42AM -0700, kan.li...@linux.intel.com wrote:
@@ -2044,6 +2056,14 @@ static void intel_pmu_disable_event(struct perf_event
*event)
if (unlikely(event->attr.precise_ip))
On 8/6/2018 2:39 PM, Peter Zijlstra wrote:
On Mon, Aug 06, 2018 at 10:23:43AM -0700, kan.li...@linux.intel.com wrote:
+static bool intel_glk_counter_freezing_broken(int cpu)
case INTEL_FAM6_ATOM_GEMINI_LAKE:
+ x86_add_quirk(intel_counter_freezing_quirk);
We really
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
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 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 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
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
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
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
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/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
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/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 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/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/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/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 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 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;
+
+
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/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/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/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/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 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
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/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/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
@@ -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 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
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/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/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/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/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 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 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/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
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 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/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 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/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/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 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
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 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 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 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 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/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/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 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 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 7/23/2018 11:16 AM, Peter Zijlstra wrote:
On Thu, Mar 08, 2018 at 06:15:39PM -0800, kan.li...@linux.intel.com wrote:
From: Kan Liang
The Extended PEBS feature, introduced in Goldmont Plus
microarchitecture, supports all events as "Extended PEBS".
Introduce flag PMU_FL_PEBS_ALL to
On 7/23/2018 12:21 PM, Peter Zijlstra wrote:
On Mon, Jul 23, 2018 at 04:59:44PM +0200, Peter Zijlstra wrote:
On Thu, Mar 08, 2018 at 06:15:41PM -0800, kan.li...@linux.intel.com wrote:
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index ef47a418d819..86149b87cce8
On 7/23/2018 12:56 PM, Liang, Kan wrote:
On 7/23/2018 12:21 PM, Peter Zijlstra wrote:
On Mon, Jul 23, 2018 at 04:59:44PM +0200, Peter Zijlstra wrote:
On Thu, Mar 08, 2018 at 06:15:41PM -0800, kan.li...@linux.intel.com
wrote:
diff --git a/arch/x86/events/intel/core.c
b/arch/x86/events
Hi Peter,
Any comments for the patch series regarding to v4 PMI handler?
Thanks,
Kan
On 8/8/2018 3:12 AM, kan.li...@linux.intel.com wrote:
From: Andi Kleen
Implements counter freezing for Arch Perfmon v4 (Skylake and
newer). This allows to speed up the PMI handler by avoiding
unnecessary
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 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
+ /*
+* 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 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/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 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 12:32 PM, Arnaldo Carvalho de Melo wrote:
Em Wed, Oct 24, 2018 at 09:23:34AM -0700, Andi Kleen escreveu:
+void perf_event_munmap(void)
+{
+ struct perf_cpu_context *cpuctx;
+ unsigned long flags;
+ struct pmu *pmu;
+
+ local_irq_save(flags);
+
On 10/24/2018 8:29 PM, Peter Zijlstra wrote:
On Wed, Oct 24, 2018 at 08:11:15AM -0700, kan.li...@linux.intel.com wrote:
+void perf_event_munmap(void)
+{
+ struct perf_cpu_context *cpuctx;
+ unsigned long flags;
+ struct pmu *pmu;
+
+ local_irq_save(flags);
It is
On 9/27/2018 8:51 AM, Peter Zijlstra wrote:
On Wed, Aug 08, 2018 at 12:12:07AM -0700, kan.li...@linux.intel.com wrote:
@@ -4325,6 +4428,8 @@ __init int intel_pmu_init(void)
x86_pmu.extra_regs = intel_skl_extra_regs;
x86_pmu.pebs_aliases =
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.
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 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 9/14/2018 5:22 AM, Alexey Budankov wrote:
Hi Andi,
On 14.09.2018 11:54, Andi Kleen wrote:
In principle the LBRs need to be flushed between threads. So does
current code.
IMHO, ideally, LBRs stack would be preserved and restored when
switching between execution stacks. That would allow
On 9/14/2018 10:27 AM, Andi Kleen wrote:
On Fri, Sep 14, 2018 at 08:39:36AM -0400, Liang, Kan wrote:
On 9/14/2018 5:22 AM, Alexey Budankov wrote:
Hi Andi,
On 14.09.2018 11:54, Andi Kleen wrote:
In principle the LBRs need to be flushed between threads. So does
current code.
IMHO
> On Tue, Dec 02, 2014 at 10:06:51AM -0500, kan.li...@intel.com wrote:
> > From: Kan Liang
> >
> > This is the user space patch for Haswell LBR call stack support.
> > For many profiling tasks we need the callgraph. For example we often
> > need to see the caller of a lock or the caller of a
>
> On Thu, Dec 04, 2014 at 12:51:42PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Dec 04, 2014 at 02:49:52PM +0000, Liang, Kan escreveu:
> > > Jiri Wrote:
> > > > looks ok to me..
> >
> > > Thanks for the review.
> >
> > >
>
> Em Tue, Nov 18, 2014 at 11:38:20AM -0500, kan.li...@intel.com escreveu:
> > From: Kan Liang
> >
> > Sometime, especially debugging scaling issue, the function level diff
> > may be high granularity. The user may want to do deeper diff analysis
> > for some cache or lock issue. The "symoff"
>
> On Thu, Nov 20, 2014 at 7:32 AM, Namhyung Kim
> wrote:
> >
> > On Wed, 19 Nov 2014 14:32:08 +, Kan Liang wrote:
> > >> On Tue, 18 Nov 2014 16:36:55 -0500, kan liang wrote:
> > >> > + if (attr->exclude_user) {
> > >> > + attr->exclude_user = 0;
> -Original Message-
> From: Jiri Olsa [mailto:jo...@redhat.com]
> Sent: Tuesday, November 18, 2014 3:25 AM
> To: Liang, Kan
> Cc: a...@kernel.org; a.p.zijls...@chello.nl; eran...@google.com; linux-
> ker...@vger.kernel.org; mi...@redhat.com; pau...@samba.org;
>
> Em Tue, Dec 02, 2014 at 10:39:18AM -0500, kan.li...@intel.com escreveu:
> > From: Kan Liang
> >
> > Currently, the perf diff only works with same binaries. That's because
> > it compares the symbol start address. It doesn't work if the perf.data
> > comes from different binaries. This patch
>
> On Thu, Nov 27, 2014 at 02:09:51PM +, Liang, Kan wrote:
> >
> >
> > > Hi Kan,
> > >
> > > On Mon, 24 Nov 2014 11:00:29 -0500, Kan Liang wrote:
> > > > From: Kan Liang
> > > >
> > > > symoff can s
> On Mon, Dec 01, 2014 at 09:40:10AM -0500, Kan Liang wrote:
>
> SNIP
>
> > +static int64_t
> > +sort__symoff_collapse(struct hist_entry *left, struct hist_entry
> > +*right) {
> > + struct symbol *sym_l = left->ms.sym;
> > + struct symbol *sym_r = right->ms.sym;
> > + u64 symoff_l,
>
> Em Fri, Nov 21, 2014 at 10:55:48AM -0500, kan.li...@intel.com escreveu:
> > From: Kan Liang
> >
> > Currently, the perf diff only works with same binaries. That's because
> > it compares the symbol start address. It doesn't work if the perf.data
> > comes from different binaries. This
> SNIP
>
> > diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
> > index f4478ce..335c3a9 100644
> > --- a/tools/perf/util/session.c
> > +++ b/tools/perf/util/session.c
> > @@ -557,15 +557,63 @@ int perf_session_queue_event(struct
> perf_session *s, union perf_event *event,
> >
>
> On Fri, 14 Nov 2014 08:44:10 -0500, kan liang wrote:
> > From: Kan Liang
> >
> > Currently, there are two call chain recording options, fp and dwarf.
> > Haswell has a new feature that utilizes the existing LBR facility to
> > record call chains. So it provides the third options to record
> On Fri, 14 Nov 2014 08:44:12 -0500, kan liang wrote:
> > + /* LBR only affects the user callchain */
> > + if (i != chain_nr) {
> > + struct branch_stack *lbr_stack = sample-
> >branch_stack;
> > + int lbr_nr = lbr_stack->nr;
> > +
> On Tue, Nov 18, 2014 at 03:13:50PM +0900, Namhyung Kim wrote:
>
> SNIP
>
> > >> > + * in "from" register, while the callee is
> stored
> > >> > + * in "to" register.
> > >> > + * For example, there is a call stack
> > >> > +
> > whole
> > > >> stack.
> > > >> > + */
> > > >>
> > > >> Andi is using some sanity checks:
> > > >> http://marc.info/?l=linux-kernel=141584447819894=2
> > > >> I guess this could be applied in here, once his patch gets in.
> > > >>
> > > >
> > > > Are you suggesting me to
>
> On Tue, 18 Nov 2014 14:01:06 +, Kan Liang wrote:
> >> On Fri, 14 Nov 2014 08:44:12 -0500, kan liang wrote:
> >> > +/* LBR only affects the user callchain */
> >> > +if (i != chain_nr) {
> >> > +struct branch_stack *lbr_stack =
>
> On Tue, 18 Nov 2014 11:38:20 -0500, kan liang wrote:
> > From: Kan Liang
> >
> > Sometime, especially debugging scaling issue, the function level diff
> > may be high granularity. The user may want to do deeper diff analysis
> > for some cache or lock issue. The "symoff" key can let the
> On Tue, 18 Nov 2014 16:36:55 -0500, kan liang wrote:
> > From: Kan Liang
> >
> > Currently, there are two call chain recording options, fp and dwarf.
> > Haswell has a new feature that utilizes the existing LBR facility to
> > record call chains. So it provides the third options to record
> PERF_SAMPLE_BRANCH_USER |
> > +
> PERF_SAMPLE_BRANCH_CALL_STACK;
> > + attr->exclude_user = 0;
>
> I think we shouldn't siletly change attr->exclude_user, if it was defined, we
> need to display warning that we are changing that or fail
>
Right, I will display a
> > +
> > + printf("... chain: nr:%" PRIu64 "\n", total_nr);
> > +
> > + for (i = 0; i < callchain_nr + 1; i++)
> > printf(". %2d: %016" PRIx64 "\n",
> >i, sample->callchain->ips[i]);
>
> so if there's lbr callstack info we dont display user stack part
Hi Peter and all,
Did you get a chance to review these patches?
Zheng is away. Should I re-send the patches?
Thanks,
Kan
>
> For many profiling tasks we need the callgraph. For example we often need
> to see the caller of a lock or the caller of a memcpy or other library
> function
> to
> SNIP
>
> > return 0;
> > }
> >
> > +static int
> > +comp_pmu(const void *p1, const void *p2) {
> > + struct perf_pmu_event_symbol *pmu1 =
> > + (struct perf_pmu_event_symbol *) p1;
> > + struct perf_pmu_event_symbol *pmu2 =
> > + (struct
> On Wed, Sep 10, 2014 at 01:55:31PM -0400, kan.li...@intel.com wrote:
>
> SNIP
>
> > + struct perf_pmu_event_symbol *pmu2 =
> > + (struct perf_pmu_event_symbol *) p2;
> > +
> > + return strcmp(pmu1->symbol, pmu2->symbol); }
> > +
> > +/*
> > + * Read the pmu events list
>
> On Tue, Sep 02, 2014 at 11:29:30AM -0400, kan.li...@intel.com wrote:
> > From: Kan Liang
>
> SNIP
>
> > }
> > +|
> > +PE_KERNEL_PMU_EVENT
> > +{
> > + struct parse_events_evlist *data = _data;
> > + struct list_head *head = malloc(sizeof(*head));
> > + struct parse_events_term
> Subject: Re: [PATCH 1/1] perf/x86: filter branches for PEBS event
>
> On Thu, Mar 26, 2015 at 11:13 AM, wrote:
> > From: Kan Liang
> >
> > For supporting Intel LBR branches filtering, Intel LBR sharing logic
> > mechanism is introduced from commit b36817e88630 ("perf/x86: Add
> Intel
> >
>
> Em Tue, Mar 03, 2015 at 05:09:29PM +, Liang, Kan escreveu:
> >
> >
> > > Em Tue, Mar 03, 2015 at 01:09:29PM -0300, Arnaldo Carvalho de Melo
> > > escreveu:
> > > > Em Tue, Mar 03, 2015 at 03:54:43AM -0500, kan.li...
901 - 1000 of 1326 matches
Mail list logo
