On 4/16/2021 12:45 PM, Peter Zijlstra wrote:
On Fri, Apr 16, 2021 at 03:01:48PM -, tip-bot2 for Kan Liang wrote:
@@ -2331,6 +2367,9 @@ static void x86_pmu_event_unmapped(struct perf_event
*event, struct mm_struct *m
if (!(event->hw.flags & PERF_X86_EVENT_RDPMC_ALLOWED))
On 4/15/2021 5:19 PM, Liang, Kan wrote:
Hi Steve,
On 4/15/2021 4:37 PM, Steve Wahl wrote:
If an uncore has no pci_init routine, or that routine fails,
uncore_pci_init is not called, and memory is not allocated for
uncore_extra_pci_dev.
So check to make sure uncore_extra_pci_dev is not NULL
Hi Steve,
On 4/15/2021 4:37 PM, Steve Wahl wrote:
If an uncore has no pci_init routine, or that routine fails,
uncore_pci_init is not called, and memory is not allocated for
uncore_extra_pci_dev.
So check to make sure uncore_extra_pci_dev is not NULL before use.
I think more after
On 4/14/2021 9:51 AM, Namhyung Kim wrote:
Hi Kan,
On Wed, Apr 14, 2021 at 4:04 AM wrote:
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index dd9f3c2..0d4a1a3 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -1585,6 +1585,8 @@ static void x86_pmu_del(struct
On 4/13/2021 4:33 PM, kernel test robot wrote:
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tip/perf/core]
[also build test WARNING on tip/master linux/master linus/master v5.12-rc7
next-20210413]
[If your patch is applied to the wrong git tree,
On 4/13/2021 8:34 PM, Andy Lutomirski wrote:
On Tue, Apr 13, 2021 at 12:05 PM wrote:
From: Kan Liang
The counter value of a perf task may leak to another RDPMC task.
For example, a perf stat task as below is running on CPU 0.
perf stat -e 'branches,cycles' -- taskset -c 0
On 4/9/2021 11:45 AM, Peter Zijlstra wrote:
On Fri, Apr 09, 2021 at 09:50:20AM -0400, Liang, Kan wrote:
On 4/9/2021 2:58 AM, Peter Zijlstra wrote:
On Mon, Apr 05, 2021 at 08:10:58AM -0700, kan.li...@linux.intel.com wrote:
@@ -2089,9 +2119,46 @@ static int __init init_hw_perf_events(void
On 4/9/2021 5:21 AM, Peter Zijlstra wrote:
On Mon, Apr 05, 2021 at 08:11:03AM -0700, kan.li...@linux.intel.com wrote:
From: Kan Liang
Current Hardware events and Hardware cache events have special perf
types, PERF_TYPE_HARDWARE and PERF_TYPE_HW_CACHE. The two types don't
pass the PMU type
On 4/9/2021 5:24 AM, Peter Zijlstra wrote:
On Mon, Apr 05, 2021 at 08:11:05AM -0700, kan.li...@linux.intel.com wrote:
From: Kan Liang
PPERF and SMI_COUNT MSRs are also supported on Alder Lake.
The External Design Specification (EDS) is not published yet. It comes
from an authoritative
On 4/9/2021 2:58 AM, Peter Zijlstra wrote:
On Mon, Apr 05, 2021 at 08:10:58AM -0700, kan.li...@linux.intel.com wrote:
@@ -2089,9 +2119,46 @@ static int __init init_hw_perf_events(void)
if (err)
goto out1;
- err = perf_pmu_register(, "cpu", PERF_TYPE_RAW);
-
On 4/8/2021 9:40 AM, Peter Zijlstra wrote:
@@ -4330,7 +4347,7 @@ static int intel_pmu_check_period(struct perf_event
*event, u64 value)
static int intel_pmu_aux_output_match(struct perf_event *event)
{
- if (!x86_pmu.intel_cap.pebs_output_pt_available)
+ if
On 4/8/2021 1:00 PM, Peter Zijlstra wrote:
On Mon, Apr 05, 2021 at 08:10:46AM -0700, kan.li...@linux.intel.com wrote:
+#define is_hybrid()(!!x86_pmu.num_hybrid_pmus)
Given this is sprinkled all over the place, can you make this a
static_key_false +
On 3/23/2021 5:41 PM, Peter Zijlstra wrote:
On Mon, Mar 22, 2021 at 02:06:33PM +0800, Like Xu wrote:
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 18df17129695..a4ce669cc78d 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -373,7 +373,7 @@
On 3/22/2021 2:06 AM, Like Xu wrote:
If the kernel is compiled with the CONFIG_LOCKDEP option, the conditional
might_sleep_if() deep in kmem_cache_alloc() will generate the following
trace, and potentially cause a deadlock when another LBR event is added:
[ 243.115549] BUG: sleeping
On 3/18/2021 9:10 PM, Namhyung Kim wrote:
Hi Kan,
On Thu, Mar 18, 2021 at 3:05 AM wrote:
From: Kan Liang
A self-describing mechanism for the uncore PerfMon hardware has been
introduced with the latest Intel platforms. By reading through an MMIO
page worth of information, perf can
On 3/18/2021 9:21 AM, Arnaldo Carvalho de Melo wrote:
Em Thu, Mar 18, 2021 at 01:16:37PM +0100, Jiri Olsa escreveu:
On Wed, Mar 17, 2021 at 10:42:45AM -0300, Arnaldo Carvalho de Melo wrote:
Em Wed, Mar 17, 2021 at 08:17:52PM +0800, Jin, Yao escreveu:
I'm OK to only support
On 3/16/2021 2:34 PM, Stephane Eranian wrote:
On Tue, Mar 16, 2021 at 5:28 AM Liang, Kan wrote:
On 3/16/2021 3:22 AM, Namhyung Kim wrote:
Hi Peter and Kan,
On Thu, Mar 4, 2021 at 5:22 AM Peter Zijlstra wrote:
On Wed, Mar 03, 2021 at 02:53:00PM -0500, Liang, Kan wrote:
On 3/3/2021 1
On 3/16/2021 10:05 AM, Peter Zijlstra wrote:
On Tue, Mar 16, 2021 at 08:42:25AM -0400, Liang, Kan wrote:
On 3/16/2021 7:43 AM, Peter Zijlstra wrote:
On Fri, Mar 12, 2021 at 08:34:34AM -0800, kan.li...@linux.intel.com wrote:
From: Kan Liang
A self-describing mechanism for the uncore
On 3/16/2021 7:43 AM, Peter Zijlstra wrote:
On Fri, Mar 12, 2021 at 08:34:34AM -0800, kan.li...@linux.intel.com wrote:
From: Kan Liang
A self-describing mechanism for the uncore PerfMon hardware has been
introduced with the latest Intel platforms. By reading through an MMIO
page worth of
On 3/16/2021 7:40 AM, Peter Zijlstra wrote:
On Fri, Mar 12, 2021 at 08:34:34AM -0800, kan.li...@linux.intel.com wrote:
+static struct intel_uncore_discovery_type *
+search_uncore_discovery_type(u16 type_id)
+{
+ struct rb_node *node = discovery_tables.rb_node;
+ struct
On 3/16/2021 3:22 AM, Namhyung Kim wrote:
Hi Peter and Kan,
On Thu, Mar 4, 2021 at 5:22 AM Peter Zijlstra wrote:
On Wed, Mar 03, 2021 at 02:53:00PM -0500, Liang, Kan wrote:
On 3/3/2021 1:59 PM, Peter Zijlstra wrote:
On Wed, Mar 03, 2021 at 05:42:18AM -0800, kan.li...@linux.intel.com
On 3/11/2021 2:58 PM, Peter Zijlstra wrote:
On Thu, Mar 11, 2021 at 11:53:35AM -0500, Liang, Kan wrote:
The "cpu_core" PMU is similar to the Sapphire Rapids PMU, but without
PMEM.
The "cpu_atom" PMU is similar to Tremont, but with different
event_constraints, e
On 3/11/2021 11:32 AM, Peter Zijlstra wrote:
On Thu, Mar 11, 2021 at 05:09:25PM +0100, Peter Zijlstra wrote:
On Wed, Mar 10, 2021 at 08:37:56AM -0800, kan.li...@linux.intel.com wrote:
From: Kan Liang
Alder Lake Hybrid system has two different types of core, Golden Cove
core and Gracemont
On 3/11/2021 11:53 AM, Liang, Kan wrote:
On 3/11/2021 11:09 AM, Peter Zijlstra wrote:
On Wed, Mar 10, 2021 at 08:37:56AM -0800, kan.li...@linux.intel.com
wrote:
From: Kan Liang
Alder Lake Hybrid system has two different types of core, Golden Cove
core and Gracemont core. The Golden Cove
On 3/11/2021 11:09 AM, Peter Zijlstra wrote:
On Wed, Mar 10, 2021 at 08:37:56AM -0800, kan.li...@linux.intel.com wrote:
From: Kan Liang
Alder Lake Hybrid system has two different types of core, Golden Cove
core and Gracemont core. The Golden Cove core is registered to
"cpu_core" PMU. The
On 3/11/2021 7:34 AM, Peter Zijlstra wrote:
On Wed, Mar 10, 2021 at 08:37:52AM -0800, kan.li...@linux.intel.com wrote:
@@ -2092,9 +2105,37 @@ static int __init init_hw_perf_events(void)
if (err)
goto out1;
- err = perf_pmu_register(, "cpu", PERF_TYPE_RAW);
-
On 3/11/2021 6:07 AM, Peter Zijlstra wrote:
On Wed, Mar 10, 2021 at 08:37:44AM -0800, kan.li...@linux.intel.com wrote:
From: Kan Liang
The hardware cache events are different among hybrid PMUs. Each hybrid
PMU should have its own hw cache event table.
Reviewed-by: Andi Kleen
On 3/10/2021 5:25 PM, Ricardo Neri wrote:
On Wed, Mar 10, 2021 at 09:01:47PM +0100, Borislav Petkov wrote:
On Wed, Mar 10, 2021 at 11:46:44AM -0800, Ricardo Neri wrote:
But this series provides the use case, right? Kan's patches handle PMU counters
that may differ cross types of CPUs. In
On 3/10/2021 11:50 AM, Dave Hansen wrote:
On 3/10/21 8:37 AM, kan.li...@linux.intel.com wrote:
- err = perf_pmu_register(, "cpu", PERF_TYPE_RAW);
- if (err)
- goto out2;
+ if (!is_hybrid()) {
+ err = perf_pmu_register(, "cpu", PERF_TYPE_RAW);
+
On 3/5/2021 6:14 AM, Peter Zijlstra wrote:
On Thu, Mar 04, 2021 at 06:50:00PM +0100, Peter Zijlstra wrote:
On Thu, Mar 04, 2021 at 10:50:45AM -0500, Liang, Kan wrote:
Hi Peter,
Could you please take a look at the perf kernel patches (3-25)?
By now, we have got some comments regarding
On 3/3/2021 3:22 PM, Vince Weaver wrote:
On Wed, 3 Mar 2021, Liang, Kan wrote:
We never use bit 58. It should be a new issue.
Actually, KVM uses it. They create a fake event called VLBR_EVENT, which
uses bit 58. It's introduced from the commit 097e4311cda9 ("perf/x86:
Add const
Hi Peter,
Could you please take a look at the perf kernel patches (3-25)?
By now, we have got some comments regarding the generic hybrid feature
enumeration code and perf tool patches. I would appreciate it very much
if you could comment on the perf kernel patches.
Thanks,
Kan
On 2/8/2021
On 3/3/2021 1:59 PM, Peter Zijlstra wrote:
On Wed, Mar 03, 2021 at 05:42:18AM -0800, kan.li...@linux.intel.com wrote:
For some old CPUs (HSW and earlier), the PEBS status in a PEBS record
may be mistakenly set to 0. To minimize the impact of the defect, the
commit was introduced to try to
On 3/3/2021 2:28 PM, Stephane Eranian wrote:
On Wed, Mar 3, 2021 at 10:16 AM Vince Weaver wrote:
Hello
on my Haswell machine the perf_fuzzer managed to trigger this message:
[117248.075892] unchecked MSR access error: WRMSR to 0x3f1 (tried to write
0x0400) at rIP:
On 3/2/2021 12:08 PM, Thomas Richter wrote:
On 3/2/21 4:23 PM, Liang, Kan wrote:
On 3/2/2021 9:48 AM, Thomas Richter wrote:
On 3/2/21 3:03 PM, Liang, Kan wrote:
+ Athira Rajeev
On 3/2/2021 8:31 AM, Thomas Richter wrote:
Executing perf test 27 fails on s390:
[root@t35lp46 perf
On 3/2/2021 9:48 AM, Thomas Richter wrote:
On 3/2/21 3:03 PM, Liang, Kan wrote:
+ Athira Rajeev
On 3/2/2021 8:31 AM, Thomas Richter wrote:
Executing perf test 27 fails on s390:
[root@t35lp46 perf]# ./perf test -Fv 27
27: Sample parsing
--- start ---
end
Sample
+ Athira Rajeev
On 3/2/2021 8:31 AM, Thomas Richter wrote:
Executing perf test 27 fails on s390:
[root@t35lp46 perf]# ./perf test -Fv 27
27: Sample parsing
--- start ---
end
Sample parsing: FAILED!
[root@t35lp46 perf]#
The root cause is
commit c7444297fd3769 ("perf
On 2/11/2021 9:53 AM, Peter Zijlstra wrote:
Kan, do you have time to look at this?
On Thu, Jan 28, 2021 at 02:49:47PM -0500, Vince Weaver wrote:
On Thu, 28 Jan 2021, Vince Weaver wrote:
the perf_fuzzer has turned up a repeatable crash on my haswell system.
addr2line is not being very
On 2/11/2021 5:14 PM, Vince Weaver wrote:
On Thu, 11 Feb 2021, Liang, Kan wrote:
On Thu, Jan 28, 2021 at 02:49:47PM -0500, Vince Weaver wrote:
I'd like to reproduce it on my machine.
Is this issue only found in a Haswell client machine?
To reproduce the issue, can I use ./perf_fuzzer
On 2/11/2021 9:53 AM, Peter Zijlstra wrote:
Kan, do you have time to look at this?
On Thu, Jan 28, 2021 at 02:49:47PM -0500, Vince Weaver wrote:
On Thu, 28 Jan 2021, Vince Weaver wrote:
the perf_fuzzer has turned up a repeatable crash on my haswell system.
addr2line is not being very
On 2/11/2021 6:40 AM, Jiri Olsa wrote:
On Mon, Feb 08, 2021 at 07:24:57AM -0800, kan.li...@linux.intel.com wrote:
SNIP
Jin Yao (24):
perf jevents: Support unit value "cpu_core" and "cpu_atom"
perf util: Save pmu name to struct perf_pmu_alias
perf pmu: Save detected hybrid pmus to
On 2/8/2021 10:58 PM, kernel test robot wrote:
Hi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/perf/core]
[cannot apply to tip/master linus/master tip/x86/core v5.11-rc6 next-20210125]
[If your patch is applied to the wrong git tree, kindly drop us a
On 2/8/2021 12:56 PM, Borislav Petkov wrote:
On Mon, Feb 08, 2021 at 07:24:59AM -0800, kan.li...@linux.intel.com wrote:
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index c20a52b..1f25ac9 100644
--- a/arch/x86/include/asm/processor.h
+++
On 2/6/2021 3:09 AM, Namhyung Kim wrote:
On Fri, Feb 5, 2021 at 11:38 PM Liang, Kan wrote:
On 2/5/2021 6:08 AM, Namhyung Kim wrote:
On Wed, Feb 3, 2021 at 5:14 AM wrote:
From: Kan Liang
The instruction latency information can be recorded on some platforms,
e.g., the Intel Sapphire
On 2/5/2021 10:26 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Feb 05, 2021 at 09:13:34AM -0500, Liang, Kan escreveu:
On 2/5/2021 5:52 AM, Namhyung Kim wrote:
On Wed, Feb 3, 2021 at 5:14 AM wrote:
From: Kan Liang
On the Intel Sapphire Rapids server, an auxiliary event has
On 2/5/2021 5:52 AM, Namhyung Kim wrote:
On Wed, Feb 3, 2021 at 5:14 AM wrote:
From: Kan Liang
On the Intel Sapphire Rapids server, an auxiliary event has to be
enabled simultaneously with the load latency event to retrieve complete
Memory Info.
Add X86 specific perf_mem_events__name()
On 2/5/2021 7:55 AM, Athira Rajeev wrote:
Because in other archs, the var2_w of ‘perf_sample_weight’ could be used to
capture something else than the Local INSTR Latency.
Can we have some weak function to populate the header string ?
I agree that the var2_w has different meanings among
On 2/5/2021 6:02 AM, Namhyung Kim wrote:
On Wed, Feb 3, 2021 at 5:14 AM wrote:
From: Kan Liang
Two new data source fields, to indicate the block reasons of a load
instruction, are introduced on the Intel Sapphire Rapids server. The
fields can be used by the memory profiling.
Add a new
On 2/5/2021 6:08 AM, Namhyung Kim wrote:
On Wed, Feb 3, 2021 at 5:14 AM wrote:
From: Kan Liang
The instruction latency information can be recorded on some platforms,
e.g., the Intel Sapphire Rapids server. With both memory latency
(weight) and the new instruction latency information,
On 2/5/2021 5:43 AM, Namhyung Kim wrote:
On Fri, Feb 5, 2021 at 12:24 AM Liang, Kan wrote:
On 2/4/2021 9:00 AM, Namhyung Kim wrote:
Hi Kan,
On Sat, Jan 30, 2021 at 2:25 AM Liang, Kan wrote:
[SNIP]
diff --git a/include/uapi/linux/perf_event.h
b/include/uapi/linux/perf_event.h
index
On 2/4/2021 9:00 AM, Namhyung Kim wrote:
Hi Kan,
On Sat, Jan 30, 2021 at 2:25 AM Liang, Kan wrote:
[SNIP]
diff --git a/include/uapi/linux/perf_event.h
b/include/uapi/linux/perf_event.h
index b15e344..c50718a 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
On 2/4/2021 8:11 AM, Athira Rajeev wrote:
On 03-Feb-2021, at 1:39 AM, kan.li...@linux.intel.com wrote:
From: Kan Liang
The instruction latency information can be recorded on some platforms,
e.g., the Intel Sapphire Rapids server. With both memory latency
(weight) and the new instruction
On 2/3/2021 3:02 PM, Arnaldo Carvalho de Melo wrote:
Em Tue, Feb 02, 2021 at 12:09:06PM -0800,kan.li...@linux.intel.com escreveu:
From: Kan Liang
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index c26ea822..c48f6de 100644
--- a/tools/perf/util/evsel.c
+++
On 2/3/2021 3:31 PM, Arnaldo Carvalho de Melo wrote:
--- a/tools/perf/util/perf_event_attr_fprintf.c
+++ b/tools/perf/util/perf_event_attr_fprintf.c
@@ -35,7 +35,7 @@ static void __p_sample_type(char *buf, size_t size, u64 value)
bit_name(BRANCH_STACK), bit_name(REGS_USER),
On 2/1/2021 9:30 AM, Peter Zijlstra wrote:
I made the below changes, does that work?
Yes, it works well.
Thanks,
Kan
---
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3627,6 +3627,15 @@ static int core_pmu_hw_config(struct per
return
On 1/28/2021 5:40 PM, kan.li...@linux.intel.com wrote:
From: Kan Liang
Current PERF_SAMPLE_WEIGHT sample type is very useful to expresses the
cost of an action represented by the sample. This allows the profiler
to scale the samples to be more informative to the programmer. It could
also
On 1/27/2021 2:03 PM, Peter Zijlstra wrote:
On Wed, Jan 27, 2021 at 07:38:41AM -0800, kan.li...@linux.intel.com wrote:
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index b15e344..13b4019 100644
--- a/include/uapi/linux/perf_event.h
+++
On 1/27/2021 2:13 PM, Peter Zijlstra wrote:
On Wed, Jan 27, 2021 at 07:38:43AM -0800, kan.li...@linux.intel.com wrote:
From: Kan Liang
Current perf doesn't check the index of a Topdown metrics event before
updating the event. A perf tool user may get a value from an unsupported
Topdown
On 1/26/2021 10:37 AM, Peter Zijlstra wrote:
On Tue, Jan 19, 2021 at 12:38:22PM -0800, kan.li...@linux.intel.com wrote:
@@ -1577,9 +1668,20 @@ static void setup_pebs_adaptive_sample_data(struct
perf_event *event,
}
if (format_size & PEBS_DATACFG_MEMINFO) {
+ if
On 1/26/2021 9:43 AM, Peter Zijlstra wrote:
On Tue, Jan 19, 2021 at 12:38:22PM -0800, kan.li...@linux.intel.com wrote:
@@ -2319,6 +2474,17 @@ static void __icl_update_topdown_event(struct perf_event
*event,
{
u64 delta, last = 0;
+ /*
+* Although the unsupported
On 1/26/2021 9:44 AM, Peter Zijlstra wrote:
On Tue, Jan 19, 2021 at 12:38:22PM -0800, kan.li...@linux.intel.com wrote:
@@ -3671,6 +3853,31 @@ static int intel_pmu_hw_config(struct perf_event *event)
}
}
+ /*
+* To retrieve complete Memory Info of the load
On 1/26/2021 9:42 AM, Peter Zijlstra wrote:
On Tue, Jan 19, 2021 at 12:38:20PM -0800, kan.li...@linux.intel.com wrote:
@@ -900,6 +901,13 @@ enum perf_event_type {
*char data[size]; } && PERF_SAMPLE_AUX
* { u64
On 1/21/2021 2:57 PM, Arnaldo Carvalho de Melo wrote:
Em Thu, Jan 21, 2021 at 05:37:52AM -0800, kan.li...@linux.intel.com escreveu:
From: Kan Liang
The Topdown Microarchitecture Analysis (TMA) Method is a structured
analysis methodology to identify critical performance bottlenecks in
On 1/15/2021 2:25 PM, Arnaldo Carvalho de Melo wrote:
Em Tue, Jan 05, 2021 at 11:57:50AM -0800,kan.li...@linux.intel.com escreveu:
From: Stephane Eranian
Display sampled code page sizes when PERF_SAMPLE_CODE_PAGE_SIZE was set.
For example,
perf script --fields comm,event,ip,code_page_size
On 1/12/2021 12:24 AM, Athira Rajeev wrote:
On 06-Jan-2021, at 1:27 AM, kan.li...@linux.intel.com wrote:
From: Kan Liang
Changes since V3:
- Rebase on top of acme's perf/core branch
commit c07b45a355ee ("perf record: Tweak "Lowering..." warning in
record_opts__config_freq")
Changes
On 1/8/2021 10:35 AM, Steve Wahl wrote:
For Intel uncore, the registers being used to identify the die don't
contain enough bits to uniquely identify more than 8 dies. On
systems with more than 8 dies, this results in error messages of the
form "skx_uncore: probe of :XX:XX.X failed with
On 1/7/2021 12:41 PM, Adrian Hunter wrote:
In some cases, the number of cpus (nr_cpus_online) is confused with the
maximum cpu number (nr_cpus_avail), which results in the error in the
example below:
Example on system with 8 cpus:
Before:
# echo 0 > /sys/devices/system/cpu/cpu2/online
On 12/19/2020 3:56 PM, Arnaldo Carvalho de Melo wrote:
Em Wed, Dec 16, 2020 at 10:58:01AM -0800, kan.li...@linux.intel.com escreveu:
From: Kan Liang
Add option --data-page-size in "perf mem" to record/report data page
size.
Here are some examples.
perf mem --phys-data --data-page-size
On 12/10/2020 2:13 AM, Namhyung Kim wrote:
Hi Peter and Kan,
How can we move this forward?
Hi Namhyung,
Thanks for the test. The changes look good to me.
Hi Peter,
Should we resend the patch set for further review?
Thanks,
Kan
Thanks,
Namhyung
On Fri, Dec 4, 2020 at 4:14 PM
On 12/7/2020 12:07 PM, Arnaldo Carvalho de Melo wrote:
Em Mon, Nov 30, 2020 at 09:27:53AM -0800, kan.li...@linux.intel.com escreveu:
From: Kan Liang
Support new sample type PERF_SAMPLE_DATA_PAGE_SIZE for page size.
Add new option --data-page-size to record sample data page size.
So,
On 12/4/2020 6:27 PM, Jiri Olsa wrote:
On Mon, Nov 30, 2020 at 09:27:57AM -0800, kan.li...@linux.intel.com wrote:
SNIP
@@ -172,7 +172,7 @@ dump_raw_samples(struct perf_tool *tool,
{
struct perf_mem *mem = container_of(tool, struct perf_mem, tool);
struct addr_location al;
On 11/27/2020 3:22 PM, Jiri Olsa wrote:
hi,
I can't compile this on Fedora 32, check the log below
The patch set was compiled with GCC 9. I will install a GCC 10 and fix
all the warnings.
Thanks,
Kan
jirka
---
$ make JOBS=1
BUILD: Doing 'make -j1' parallel build
Warning: Kernel
, Nov 12, 2020 at 4:54 AM Liang, Kan
wrote:
On 11/11/2020 11:25 AM, Peter Zijlstra wrote:
On Mon, Nov 09, 2020 at 09:49:31AM -0500, Liang, Kan wrote:
- When the large PEBS was introduced (9c964efa4330), the
sched_task() should
be invoked to flush the PEBS buffer in each context switch
On 11/13/2020 6:19 AM, Peter Zijlstra wrote:
The (new) page-table walker in arch_perf_get_page_size() is broken in
various ways. Specifically while it is used in a locless manner, it
doesn't depend on CONFIG_HAVE_FAST_GUP nor uses the proper _lockless
offset methods, nor is careful to only
On 11/11/2020 11:25 AM, Peter Zijlstra wrote:
On Mon, Nov 09, 2020 at 09:49:31AM -0500, Liang, Kan wrote:
- When the large PEBS was introduced (9c964efa4330), the sched_task() should
be invoked to flush the PEBS buffer in each context switch. However, The
perf_sched_events in account_event
On 11/4/2020 12:11 PM, Liang, Kan wrote:
On 10/13/2020 12:34 PM, Peter Zijlstra wrote:
Subject: perf,mm: Handle non-page-table-aligned hugetlbfs
From: Peter Zijlstra
Date: Fri, 9 Oct 2020 11:09:27 +0200
A limited nunmber of architectures support hugetlbfs sizes that do not
align
On 11/9/2020 12:33 PM, Peter Zijlstra wrote:
On Mon, Nov 09, 2020 at 09:49:31AM -0500, Liang, Kan wrote:
Maybe we can frob x86_pmu_enable()...
Could you please elaborate?
Something horrible like this. It will detect the first time we enable
the PMU on a new task (IOW we did a context
On 11/9/2020 6:04 AM, Peter Zijlstra wrote:
On Mon, Nov 09, 2020 at 10:52:35AM +0100, Peter Zijlstra wrote:
On Fri, Nov 06, 2020 at 01:29:33PM -0800, kan.li...@linux.intel.com wrote:
From: Kan Liang
Sometimes the PMU internal buffers have to be flushed for per-CPU events
during a context
On 11/5/2020 7:53 PM, Namhyung Kim wrote:
On Fri, Nov 6, 2020 at 4:01 AM Liang, Kan wrote:
On 11/5/2020 10:45 AM, Namhyung Kim wrote:
Hello,
On Thu, Nov 5, 2020 at 11:47 PM Liang, Kan wrote:
On 11/2/2020 9:52 AM, Namhyung Kim wrote:
If an event associated with a PMU which has
On 11/5/2020 4:15 PM, Stephane Eranian wrote:
On Thu, Nov 5, 2020 at 11:40 AM Liang, Kan wrote:
On 11/5/2020 10:54 AM, Namhyung Kim wrote:
-void perf_sched_cb_inc(struct pmu *pmu)
+void perf_sched_cb_inc(struct pmu *pmu, bool systemwide)
{
struct perf_cpu_context *cpuctx
On 11/5/2020 10:54 AM, Namhyung Kim wrote:
-void perf_sched_cb_inc(struct pmu *pmu)
+void perf_sched_cb_inc(struct pmu *pmu, bool systemwide)
{
struct perf_cpu_context *cpuctx = this_cpu_ptr(pmu->pmu_cpu_context);
- if (!cpuctx->sched_cb_usage++)
-
On 11/5/2020 10:45 AM, Namhyung Kim wrote:
Hello,
On Thu, Nov 5, 2020 at 11:47 PM Liang, Kan wrote:
On 11/2/2020 9:52 AM, Namhyung Kim wrote:
If an event associated with a PMU which has a sched_task callback,
it should be called regardless of cpu/task context. For example,
I don't
On 11/2/2020 9:52 AM, Namhyung Kim wrote:
The commit 44fae179ce73 ("perf/core: Pull pmu::sched_task() into
perf_event_context_sched_out()") moved the pmu::sched_task callback to
be called for task event context. But it missed to call it for
per-cpu events to flush PMU internal buffers (i.e.
On 11/2/2020 9:52 AM, Namhyung Kim wrote:
If an event associated with a PMU which has a sched_task callback,
it should be called regardless of cpu/task context. For example,
I don't think it's necessary. We should call it when we have to.
Otherwise, it just waste cycles.
Shouldn't the
On 10/13/2020 12:34 PM, Peter Zijlstra wrote:
Subject: perf,mm: Handle non-page-table-aligned hugetlbfs
From: Peter Zijlstra
Date: Fri, 9 Oct 2020 11:09:27 +0200
A limited nunmber of architectures support hugetlbfs sizes that do not
align with the page-tables (ARM64, Power, Sparc64). Add
On 10/19/2020 12:09 PM, Andi Kleen wrote:
Reported-by: Andi Kleen
Signed-off-by: Kan Liang
I guess this should have a Fixes: tag and also be proposed for
stable.
I will send V2 shortly to update the tag and Cc.
Thanks,
Kan
On 10/12/2020 4:48 AM, Will Deacon wrote:
On Sat, Oct 10, 2020 at 12:28:39AM +1100, Michael Ellerman wrote:
Peter Zijlstra writes:
Patch 4 makes it all far worse by exposing it to pretty much everybody.
Now, I think we can fix at least the user mappings with the below delta,
but if archs
On 10/9/2020 5:09 AM, Peter Zijlstra wrote:
(we might not need the #ifdef gunk, but I've not yet dug out my cross
compilers this morning)
---
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7009,6 +7009,7 @@ static u64 perf_virt_to_phys(u64 virt)
*/
static u64
On 10/2/2020 7:02 AM, Peter Zijlstra wrote:
On Wed, Sep 30, 2020 at 07:29:35AM -0700, kan.li...@linux.intel.com wrote:
From: Kan Liang
When a group that has TopDown members is failed to be scheduled, any
later TopDown groups will not return valid values.
Here is an example.
A background
On 9/30/2020 6:45 PM, Stephane Eranian wrote:
On Wed, Sep 30, 2020 at 10:30 AM Peter Zijlstra wrote:
On Wed, Sep 30, 2020 at 07:48:48AM -0700, Dave Hansen wrote:
On 9/30/20 7:42 AM, Liang, Kan wrote:
When I tested on my kernel, it panicked because I suspect
current->active_mm co
On 9/30/2020 3:15 AM, Stephane Eranian wrote:
+static u64 perf_get_page_size(unsigned long addr)
+{
+ unsigned long flags;
+ u64 size;
+
+ if (!addr)
+ return 0;
+
+ /*
+* Software page-table walkers must disable IRQs,
+* which prevents
On 9/21/2020 6:19 PM, Bjorn Helgaas wrote:
On Mon, Sep 14, 2020 at 07:34:19AM -0700, kan.li...@linux.intel.com wrote:
From: Kan Liang
Some uncore counters may be located in the configuration space of a PCI
device, which already has a bonded driver. Currently, the uncore driver
cannot
On 9/17/2020 6:02 PM, Dave Hansen wrote:
The problem is that the warning from the perf tool usually includes some
hints regarding the cause of the warning or possible solution to
workaround/fix the warning. What message should we deliver to the users?
"Warning: Too many error page size.
On 9/17/2020 5:24 PM, Dave Hansen wrote:
On 9/17/20 2:16 PM, Liang, Kan wrote:
One last concern as I look at this: I wish it was a bit more
future-proof. There are lots of weird things folks are trying to do
with the page tables, like Address Space Isolation. For instance, if
you get
On 9/17/2020 3:00 PM, Dave Hansen wrote:
On 9/17/20 6:52 AM, kan.li...@linux.intel.com wrote:
+ mm = current->mm;
+ if (!mm) {
+ /*
+* For kernel threads and the like, use init_mm so that
+* we can find kernel memory.
+
On 9/10/2020 11:37 PM, Namhyung Kim wrote:
Hello,
On Thu, Sep 10, 2020 at 10:48 PM wrote:
From: Andi Kleen
Icelake has support for reporting per thread TopDown metrics.
These are reported differently than the previous TopDown support,
each metric is standalone, but scaled to pipeline
On 9/8/2020 11:58 AM, pet...@infradead.org wrote:
> On Mon, Sep 07, 2020 at 06:01:15PM +0200, pet...@infradead.org wrote:
>> On Fri, Aug 21, 2020 at 12:57:54PM -0700, kan.li...@linux.intel.com
>>> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
>>> index 0f3d01562ded..fa08d810dcd2
Hi Peter,
Could you please share the comments for this patch set?
Thanks,
Kan
On 8/5/2020 4:24 PM, kan.li...@linux.intel.com wrote:
From: Kan Liang
Changes since V1:
- Drop the platform device solution
- A new uncore PCI sub driver solution is introduced which searches
the PCIe Root Port
On 8/26/2020 11:54 AM, Jiri Olsa wrote:
On Thu, Aug 20, 2020 at 09:45:28AM -0700, kan.li...@linux.intel.com wrote:
From: Kan Liang
The kernel patches have been merged into the tip's perf/core branch.
The patch set is on top of commit 2cb5383b30d4 ("perf/x86/intel: Support
per-thread RDPMC
On 8/12/2020 8:21 AM, Arnaldo Carvalho de Melo wrote:
Em Mon, Aug 10, 2020 at 02:24:26PM -0700, Kan Liang escreveu:
The Bitwise-Shift operator (1U << ) is used in the enum
perf_output_field, which has already reached its capacity (32 items).
If more items are added, a compile error will be
1 - 100 of 1326 matches
Mail list logo
