Re: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches

On 3/13/2018 1:16 PM, Liang, Kan wrote: On 3/13/2018 11:58 AM, Andy Shevchenko wrote: On Tue, Mar 13, 2018 at 3:42 AM, Liang, Kan <kan.li...@linux.intel.com> wrote: +#define SKX_CAPID6 0x9c +#define SKX_CHA_BIT_WIDTH  28 +   static int skx_count_chabo

Re: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches

On 3/13/2018 1:16 PM, Liang, Kan wrote: On 3/13/2018 11:58 AM, Andy Shevchenko wrote: On Tue, Mar 13, 2018 at 3:42 AM, Liang, Kan wrote: +#define SKX_CAPID6 0x9c +#define SKX_CHA_BIT_WIDTH  28 +   static int skx_count_chabox(void)   { +   struct pci_dev *dev = NULL

Re: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches

On 3/13/2018 1:22 PM, Andy Shevchenko wrote: On Tue, Mar 13, 2018 at 7:15 PM, Liang, Kan <kan.li...@linux.intel.com> wrote: On 3/13/2018 12:00 PM, Andy Shevchenko wrote: On Tue, Mar 13, 2018 at 5:58 PM, Andy Shevchenko <andy.shevche...@gmail.com> wrote: On Tue, Mar 13, 201

Re: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches

On 3/13/2018 1:22 PM, Andy Shevchenko wrote: On Tue, Mar 13, 2018 at 7:15 PM, Liang, Kan wrote: On 3/13/2018 12:00 PM, Andy Shevchenko wrote: On Tue, Mar 13, 2018 at 5:58 PM, Andy Shevchenko wrote: On Tue, Mar 13, 2018 at 3:42 AM, Liang, Kan wrote: +#define SKX_CAPID6 0x9c

Re: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches

On 3/13/2018 11:58 AM, Andy Shevchenko wrote: On Tue, Mar 13, 2018 at 3:42 AM, Liang, Kan <kan.li...@linux.intel.com> wrote: +#define SKX_CAPID6 0x9c +#define SKX_CHA_BIT_WIDTH 28 + static int skx_count_chabox(void) { + struct pci_dev *dev = NULL; + u

Re: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches

On 3/13/2018 11:58 AM, Andy Shevchenko wrote: On Tue, Mar 13, 2018 at 3:42 AM, Liang, Kan wrote: +#define SKX_CAPID6 0x9c +#define SKX_CHA_BIT_WIDTH 28 + static int skx_count_chabox(void) { + struct pci_dev *dev = NULL; + u32 val = 0; + dev

Re: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches

On 3/13/2018 12:00 PM, Andy Shevchenko wrote: On Tue, Mar 13, 2018 at 5:58 PM, Andy Shevchenko <andy.shevche...@gmail.com> wrote: On Tue, Mar 13, 2018 at 3:42 AM, Liang, Kan <kan.li...@linux.intel.com> wrote: +#define SKX_CAPID6 0x9c + pci_read_conf

Re: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches

On 3/13/2018 12:00 PM, Andy Shevchenko wrote: On Tue, Mar 13, 2018 at 5:58 PM, Andy Shevchenko wrote: On Tue, Mar 13, 2018 at 3:42 AM, Liang, Kan wrote: +#define SKX_CAPID6 0x9c + pci_read_config_dword(dev, SKX_CAPID6, ); Moreover, this is too non-flexible. Can't

Re: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches

! Gary -----Original Message- From: Liang, Kan [mailto:kan.li...@linux.intel.com] Sent: Monday, March 12, 2018 8:43 PM To: Kroening, Gary; mi...@redhat.com; h...@zytor.com; t...@linutronix.de; pet...@infradead.org Cc: Travis, Mike; Banman, Andrew; Sivanich, Dimitri; Anderson, Russ; x...@

Re: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches

! Gary -----Original Message- From: Liang, Kan [mailto:kan.li...@linux.intel.com] Sent: Monday, March 12, 2018 8:43 PM To: Kroening, Gary; mi...@redhat.com; h...@zytor.com; t...@linutronix.de; pet...@infradead.org Cc: Travis, Mike; Banman, Andrew; Sivanich, Dimitri; Anderson, Russ; x...@

Re: [PATCH] perf/x86/uncore: Add missing filter constraint for SKX CHA event

On 3/12/2018 12:39 PM, Peter Zijlstra wrote: On Mon, Mar 12, 2018 at 08:41:34AM -0700, Kan Liang wrote: From: Stephane Eranian Adding a filter constraint for Intel Skylake CHA event UNC_CHA_UPI_CREDITS_ACQUIRED (0x38). The event supports core-id/thread-id and link

Re: [PATCH] perf/x86/uncore: Add missing filter constraint for SKX CHA event

On 3/12/2018 12:39 PM, Peter Zijlstra wrote: On Mon, Mar 12, 2018 at 08:41:34AM -0700, Kan Liang wrote: From: Stephane Eranian Adding a filter constraint for Intel Skylake CHA event UNC_CHA_UPI_CREDITS_ACQUIRED (0x38). The event supports core-id/thread-id and link filtering. Could you

Re: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches

On 3/7/2018 3:33 PM, Kroening, Gary wrote: For systems with a single PCI segment, it is sufficient to look for the bus number to change in order to determine that all of the CHa's have been counted for a single socket. However, for multi PCI segment systems, each socket is given a new segment

Re: [PATCH 1/1] x86/platform/x86: Fix count of CHas on multi-pci-segment arches

On 3/7/2018 3:33 PM, Kroening, Gary wrote: For systems with a single PCI segment, it is sufficient to look for the bus number to change in order to determine that all of the CHa's have been counted for a single socket. However, for multi PCI segment systems, each socket is given a new segment

Re: [tip:perf/core] perf/x86/intel: Disable userspace RDPMC usage for large PEBS

On 3/9/2018 2:10 PM, Vince Weaver wrote: On Fri, 9 Mar 2018, Peter Zijlstra wrote: On Fri, Mar 09, 2018 at 09:31:11AM -0500, Vince Weaver wrote: On Fri, 9 Mar 2018, tip-bot for Kan Liang wrote: Commit-ID: 1af22eba248efe2de25658041a80a3d40fb3e92e Gitweb:

Re: [tip:perf/core] perf/x86/intel: Disable userspace RDPMC usage for large PEBS

On 3/9/2018 2:10 PM, Vince Weaver wrote: On Fri, 9 Mar 2018, Peter Zijlstra wrote: On Fri, Mar 09, 2018 at 09:31:11AM -0500, Vince Weaver wrote: On Fri, 9 Mar 2018, tip-bot for Kan Liang wrote: Commit-ID: 1af22eba248efe2de25658041a80a3d40fb3e92e Gitweb:

Re: [tip:perf/core] perf/x86/intel: Disable userspace RDPMC usage for large PEBS

On 3/9/2018 12:42 PM, Peter Zijlstra wrote: On Fri, Mar 09, 2018 at 09:31:11AM -0500, Vince Weaver wrote: On Fri, 9 Mar 2018, tip-bot for Kan Liang wrote: Commit-ID: 1af22eba248efe2de25658041a80a3d40fb3e92e Gitweb: https://git.kernel.org/tip/1af22eba248efe2de25658041a80a3d40fb3e92e

Re: [tip:perf/core] perf/x86/intel: Disable userspace RDPMC usage for large PEBS

On 3/9/2018 12:42 PM, Peter Zijlstra wrote: On Fri, Mar 09, 2018 at 09:31:11AM -0500, Vince Weaver wrote: On Fri, 9 Mar 2018, tip-bot for Kan Liang wrote: Commit-ID: 1af22eba248efe2de25658041a80a3d40fb3e92e Gitweb: https://git.kernel.org/tip/1af22eba248efe2de25658041a80a3d40fb3e92e

Re: [PATCH 7/7] perf tools: Refine perf_mmap__read_init

On 3/5/2018 5:25 PM, Jiri Olsa wrote: On Mon, Mar 05, 2018 at 02:10:59PM -0500, kan.li...@linux.intel.com wrote: SNIP diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c index e3921ed..403c5e6 100644 --- a/tools/perf/util/mmap.c +++ b/tools/perf/util/mmap.c @@ -235,16 +235,13 @@

Re: [PATCH 7/7] perf tools: Refine perf_mmap__read_init

On 3/5/2018 5:25 PM, Jiri Olsa wrote: On Mon, Mar 05, 2018 at 02:10:59PM -0500, kan.li...@linux.intel.com wrote: SNIP diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c index e3921ed..403c5e6 100644 --- a/tools/perf/util/mmap.c +++ b/tools/perf/util/mmap.c @@ -235,16 +235,13 @@

Re: [PATCH 1/7] perf mmap: Store mmap scope and type in struct perf_mmap

On 3/5/2018 3:20 PM, Arnaldo Carvalho de Melo wrote: Em Mon, Mar 05, 2018 at 02:10:53PM -0500, kan.li...@linux.intel.com escreveu: From: Kan Liang There are too many boilerplates for the perf_mmap__read*() interfaces. Some of the data (e.g. 'start', 'end',

Re: [PATCH 1/7] perf mmap: Store mmap scope and type in struct perf_mmap

On 3/5/2018 3:20 PM, Arnaldo Carvalho de Melo wrote: Em Mon, Mar 05, 2018 at 02:10:53PM -0500, kan.li...@linux.intel.com escreveu: From: Kan Liang There are too many boilerplates for the perf_mmap__read*() interfaces. Some of the data (e.g. 'start', 'end', 'overwrite') should be stored in

Re: [PATCH 02/14] perf trace: Apply new perf_mmap__read_event() interface

On 3/5/2018 8:46 AM, Arnaldo Carvalho de Melo wrote: Em Mon, Mar 05, 2018 at 10:03:39AM -0300, Arnaldo Carvalho de Melo escreveu: Em Sat, Mar 03, 2018 at 12:30:22AM +0100, Jiri Olsa escreveu: On Thu, Mar 01, 2018 at 06:08:59PM -0500, kan.li...@linux.intel.com wrote: From: Kan Liang

Re: [PATCH 02/14] perf trace: Apply new perf_mmap__read_event() interface

On 3/5/2018 8:46 AM, Arnaldo Carvalho de Melo wrote: Em Mon, Mar 05, 2018 at 10:03:39AM -0300, Arnaldo Carvalho de Melo escreveu: Em Sat, Mar 03, 2018 at 12:30:22AM +0100, Jiri Olsa escreveu: On Thu, Mar 01, 2018 at 06:08:59PM -0500, kan.li...@linux.intel.com wrote: From: Kan Liang The

Re: [PATCH 02/14] perf trace: Apply new perf_mmap__read_event() interface

On 3/2/2018 6:30 PM, Jiri Olsa wrote: On Thu, Mar 01, 2018 at 06:08:59PM -0500, kan.li...@linux.intel.com wrote: From: Kan Liang The perf trace still use the legacy interface. Apply the new perf_mmap__read_event() interface for perf trace. No functional change.

Re: [PATCH 02/14] perf trace: Apply new perf_mmap__read_event() interface

On 3/2/2018 6:30 PM, Jiri Olsa wrote: On Thu, Mar 01, 2018 at 06:08:59PM -0500, kan.li...@linux.intel.com wrote: From: Kan Liang The perf trace still use the legacy interface. Apply the new perf_mmap__read_event() interface for perf trace. No functional change. Signed-off-by: Kan Liang

Re: [PATCH V4 1/5] perf/x86/intel: Fix event update for auto-reload

On 2/21/2018 5:32 AM, Peter Zijlstra wrote: On Mon, Feb 12, 2018 at 02:20:31PM -0800, kan.li...@linux.intel.com wrote: @@ -1389,8 +1456,22 @@ static void intel_pmu_drain_pebs_nhm(struct pt_regs *iregs) ds->pebs_index = ds->pebs_buffer_base; - if (unlikely(base >= top)) + if

Re: [PATCH V4 1/5] perf/x86/intel: Fix event update for auto-reload

On 2/21/2018 5:32 AM, Peter Zijlstra wrote: On Mon, Feb 12, 2018 at 02:20:31PM -0800, kan.li...@linux.intel.com wrote: @@ -1389,8 +1456,22 @@ static void intel_pmu_drain_pebs_nhm(struct pt_regs *iregs) ds->pebs_index = ds->pebs_buffer_base; - if (unlikely(base >= top)) + if

Re: [perf/x86/intel] 41e062cd2e: WARNING:at_arch/x86/events/intel/ds.c:#intel_pmu_save_and_restart_reload

On 2/19/2018 7:44 AM, Peter Zijlstra wrote: On Sat, Feb 17, 2018 at 02:21:19PM +0800, kernel test robot wrote: [ 242.731381] WARNING: CPU: 3 PID: 1107 at arch/x86/events/intel/ds.c:1326 intel_pmu_save_and_restart_reload+0x87/0x90 That's the one asserting the PMU is in fact disabled. [

Re: [perf/x86/intel] 41e062cd2e: WARNING:at_arch/x86/events/intel/ds.c:#intel_pmu_save_and_restart_reload

On 2/19/2018 7:44 AM, Peter Zijlstra wrote: On Sat, Feb 17, 2018 at 02:21:19PM +0800, kernel test robot wrote: [ 242.731381] WARNING: CPU: 3 PID: 1107 at arch/x86/events/intel/ds.c:1326 intel_pmu_save_and_restart_reload+0x87/0x90 That's the one asserting the PMU is in fact disabled. [

Re: [PATCH V3 1/5] perf/x86/intel: fix event update for auto-reload

On 2/9/2018 9:09 AM, Peter Zijlstra wrote: On Tue, Feb 06, 2018 at 12:58:23PM -0500, Liang, Kan wrote: With the exception of handling 'empty' buffers, I ended up with the below. Please try again. There are two small errors. After fixing them, the patch works well. Well, it still

Re: [PATCH V3 1/5] perf/x86/intel: fix event update for auto-reload

On 2/9/2018 9:09 AM, Peter Zijlstra wrote: On Tue, Feb 06, 2018 at 12:58:23PM -0500, Liang, Kan wrote: With the exception of handling 'empty' buffers, I ended up with the below. Please try again. There are two small errors. After fixing them, the patch works well. Well, it still

Re: [PATCH V3 1/5] perf/x86/intel: fix event update for auto-reload

With the exception of handling 'empty' buffers, I ended up with the below. Please try again. There are two small errors. After fixing them, the patch works well. --- --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -1156,16 +1156,13 @@ int x86_perf_event_set_period(struct per

Re: [PATCH V3 1/5] perf/x86/intel: fix event update for auto-reload

With the exception of handling 'empty' buffers, I ended up with the below. Please try again. There are two small errors. After fixing them, the patch works well. --- --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -1156,16 +1156,13 @@ int x86_perf_event_set_period(struct per

RE: [PATCH V5 12/17] perf evsel: expose perf_missing_features.write_backward

> Em Thu, Jan 18, 2018 at 01:26:27PM -0800, kan.li...@intel.com escreveu: > > From: Kan Liang > > > > perf top need it to handle overwrite fallback later. > > > > Signed-off-by: Kan Liang > > --- > > tools/perf/util/evsel.c | 5 + > >

RE: [PATCH V5 12/17] perf evsel: expose perf_missing_features.write_backward

> Em Thu, Jan 18, 2018 at 01:26:27PM -0800, kan.li...@intel.com escreveu: > > From: Kan Liang > > > > perf top need it to handle overwrite fallback later. > > > > Signed-off-by: Kan Liang > > --- > > tools/perf/util/evsel.c | 5 + > > tools/perf/util/evsel.h | 2 ++ > > 2 files changed, 7

RE: [PATCH V5 02/17] perf mmap: fix: recalculate size for overwrite mode.

> Em Thu, Jan 18, 2018 at 01:26:17PM -0800, kan.li...@intel.com escreveu: > > From: Kan Liang > > > > In perf_mmap__push(), the 'size' need to be recalculated, otherwise > > the invalid data might be pushed to the record in overwrite mode. > > > > The issue is introduced by

RE: [PATCH V5 02/17] perf mmap: fix: recalculate size for overwrite mode.

> Em Thu, Jan 18, 2018 at 01:26:17PM -0800, kan.li...@intel.com escreveu: > > From: Kan Liang > > > > In perf_mmap__push(), the 'size' need to be recalculated, otherwise > > the invalid data might be pushed to the record in overwrite mode. > > > > The issue is introduced by commit 7fb4b407a124

Re: [PATCH V3 0/5] bugs fix for large PEBS mmap read and rdpmc read

On 1/31/2018 8:15 AM, Jiri Olsa wrote: On Wed, Jan 31, 2018 at 10:15:39AM +0100, Jiri Olsa wrote: On Tue, Jan 30, 2018 at 07:59:41PM -0800, Andi Kleen wrote: Still, the part I am missing here, is why asking for PERF_SAMPLE_PERIOD voids large PEBS. I think it was disabled together with

Re: [PATCH V3 0/5] bugs fix for large PEBS mmap read and rdpmc read

On 1/31/2018 8:15 AM, Jiri Olsa wrote: On Wed, Jan 31, 2018 at 10:15:39AM +0100, Jiri Olsa wrote: On Tue, Jan 30, 2018 at 07:59:41PM -0800, Andi Kleen wrote: Still, the part I am missing here, is why asking for PERF_SAMPLE_PERIOD voids large PEBS. I think it was disabled together with

Re: [PATCH V3 0/5] bugs fix for large PEBS mmap read and rdpmc read

On 1/30/2018 11:36 AM, Stephane Eranian wrote: On Tue, Jan 30, 2018 at 7:25 AM, Liang, Kan <kan.li...@linux.intel.com> wrote: On 1/30/2018 10:04 AM, Jiri Olsa wrote: On Tue, Jan 30, 2018 at 09:59:15AM -0500, Liang, Kan wrote: On 1/30/2018 8:39 AM, Jiri Olsa wrote: On Tue,

Re: [PATCH V3 0/5] bugs fix for large PEBS mmap read and rdpmc read

On 1/30/2018 11:36 AM, Stephane Eranian wrote: On Tue, Jan 30, 2018 at 7:25 AM, Liang, Kan wrote: On 1/30/2018 10:04 AM, Jiri Olsa wrote: On Tue, Jan 30, 2018 at 09:59:15AM -0500, Liang, Kan wrote: On 1/30/2018 8:39 AM, Jiri Olsa wrote: On Tue, Jan 30, 2018 at 01:16:39AM -0800

Re: [PATCH V3 0/5] bugs fix for large PEBS mmap read and rdpmc read

On 1/30/2018 10:04 AM, Jiri Olsa wrote: On Tue, Jan 30, 2018 at 09:59:15AM -0500, Liang, Kan wrote: On 1/30/2018 8:39 AM, Jiri Olsa wrote: On Tue, Jan 30, 2018 at 01:16:39AM -0800, Stephane Eranian wrote: Hi, On Mon, Jan 29, 2018 at 8:29 AM, <kan.li...@linux.intel.com> wrote: Fro

Re: [PATCH V3 0/5] bugs fix for large PEBS mmap read and rdpmc read

On 1/30/2018 10:04 AM, Jiri Olsa wrote: On Tue, Jan 30, 2018 at 09:59:15AM -0500, Liang, Kan wrote: On 1/30/2018 8:39 AM, Jiri Olsa wrote: On Tue, Jan 30, 2018 at 01:16:39AM -0800, Stephane Eranian wrote: Hi, On Mon, Jan 29, 2018 at 8:29 AM, wrote: From: Kan Liang -- Changes

Re: [PATCH V3 0/5] bugs fix for large PEBS mmap read and rdpmc read

On 1/30/2018 8:39 AM, Jiri Olsa wrote: On Tue, Jan 30, 2018 at 01:16:39AM -0800, Stephane Eranian wrote: Hi, On Mon, Jan 29, 2018 at 8:29 AM, wrote: From: Kan Liang -- Changes since V2: - Refined the changelog - Introduced

Re: [PATCH V3 0/5] bugs fix for large PEBS mmap read and rdpmc read

On 1/30/2018 8:39 AM, Jiri Olsa wrote: On Tue, Jan 30, 2018 at 01:16:39AM -0800, Stephane Eranian wrote: Hi, On Mon, Jan 29, 2018 at 8:29 AM, wrote: From: Kan Liang -- Changes since V2: - Refined the changelog - Introduced specific read function for large PEBS. The previous

Re: [PATCH V3 0/5] bugs fix for large PEBS mmap read and rdpmc read

On 1/30/2018 4:16 AM, Stephane Eranian wrote: Hi, On Mon, Jan 29, 2018 at 8:29 AM, wrote: From: Kan Liang -- Changes since V2: - Refined the changelog - Introduced specific read function for large PEBS. The previous

Re: [PATCH V3 0/5] bugs fix for large PEBS mmap read and rdpmc read

On 1/30/2018 4:16 AM, Stephane Eranian wrote: Hi, On Mon, Jan 29, 2018 at 8:29 AM, wrote: From: Kan Liang -- Changes since V2: - Refined the changelog - Introduced specific read function for large PEBS. The previous generic PEBS read function is confusing. Disabled PMU

RE: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

> On Tue, Jan 23, 2018 at 10:00:58PM +0000, Liang, Kan wrote: > > > On Fri, Jan 19, 2018 at 12:24:17PM -0800, Andi Kleen wrote: > > > > > Oh, think a bit more. > > > > > I think we cannot do the same thing as we did for CPU PMU's fixed > > > count

RE: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

> On Tue, Jan 23, 2018 at 10:00:58PM +0000, Liang, Kan wrote: > > > On Fri, Jan 19, 2018 at 12:24:17PM -0800, Andi Kleen wrote: > > > > > Oh, think a bit more. > > > > > I think we cannot do the same thing as we did for CPU PMU's fixed > > > count

Re: [RESEND PATCH V2 1/4] perf/x86/intel: fix event update for auto-reload

On 1/24/2018 7:26 AM, Peter Zijlstra wrote: On Mon, Jan 08, 2018 at 07:15:13AM -0800, kan.li...@intel.com wrote: The formula to calculate the event->count is as below: event->count = period left from last time + (reload_times - 1) * reload_val +

Re: [RESEND PATCH V2 1/4] perf/x86/intel: fix event update for auto-reload

On 1/24/2018 7:26 AM, Peter Zijlstra wrote: On Mon, Jan 08, 2018 at 07:15:13AM -0800, kan.li...@intel.com wrote: The formula to calculate the event->count is as below: event->count = period left from last time + (reload_times - 1) * reload_val +

RE: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

> On Fri, Jan 19, 2018 at 12:24:17PM -0800, Andi Kleen wrote: > > > Oh, think a bit more. > > > I think we cannot do the same thing as we did for CPU PMU's fixed > counters. > > > > > > The counters here are free running counters. They cannot be start/stop. > > > > Yes free running counter have

RE: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

> On Fri, Jan 19, 2018 at 12:24:17PM -0800, Andi Kleen wrote: > > > Oh, think a bit more. > > > I think we cannot do the same thing as we did for CPU PMU's fixed > counters. > > > > > > The counters here are free running counters. They cannot be start/stop. > > > > Yes free running counter have

RE: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

> On Fri, Jan 19, 2018 at 9:53 AM, Liang, Kan <kan.li...@intel.com> wrote: > >> On Fri, Jan 19, 2018 at 03:15:00PM +, Liang, Kan wrote: > >> > > > >> > > On Thu, Jan 18, 2018 at 05:43:10PM +, Liang, Kan wrote: > >> > > &g

RE: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

> On Fri, Jan 19, 2018 at 9:53 AM, Liang, Kan wrote: > >> On Fri, Jan 19, 2018 at 03:15:00PM +0000, Liang, Kan wrote: > >> > > > >> > > On Thu, Jan 18, 2018 at 05:43:10PM +, Liang, Kan wrote: > >> > > > In the uncore document

RE: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

> On Fri, Jan 19, 2018 at 03:15:00PM +0000, Liang, Kan wrote: > > > > > > On Thu, Jan 18, 2018 at 05:43:10PM +, Liang, Kan wrote: > > > > In the uncore document, there is no event-code assigned to free > > > > running > > > counters. >

RE: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

> On Fri, Jan 19, 2018 at 03:15:00PM +0000, Liang, Kan wrote: > > > > > > On Thu, Jan 18, 2018 at 05:43:10PM +, Liang, Kan wrote: > > > > In the uncore document, there is no event-code assigned to free > > > > running > > > counters. >

RE: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

> > On Thu, Jan 18, 2018 at 05:43:10PM +, Liang, Kan wrote: > > In the uncore document, there is no event-code assigned to free running > counters. > > Some events need to be defined to indicate the free running counters. > > The events are encoded

RE: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

> > On Thu, Jan 18, 2018 at 05:43:10PM +, Liang, Kan wrote: > > In the uncore document, there is no event-code assigned to free running > counters. > > Some events need to be defined to indicate the free running counters. > > The events are encoded

RE: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

> On Mon, Jan 15, 2018 at 10:57:05AM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > There are a number of free running counters introduced for uncore, which > > provide highly valuable information to a wide array of customers. > > For example, Skylake Server

RE: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

> On Mon, Jan 15, 2018 at 10:57:05AM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > There are a number of free running counters introduced for uncore, which > > provide highly valuable information to a wide array of customers. > > For example, Skylake Server has IIO free running

Re: [RESEND PATCH V2 3/4] perf/x86/intel: drain PEBS buffer in event read

On 1/18/2018 4:49 AM, Jiri Olsa wrote: On Tue, Jan 16, 2018 at 01:49:13PM -0500, Liang, Kan wrote: On 1/11/2018 10:45 AM, Jiri Olsa wrote: On Thu, Jan 11, 2018 at 10:21:25AM -0500, Liang, Kan wrote: SNIP hum, but the PEBS drain is specific just for PERF_X86_EVENT_AUTO_RELOAD events

Re: [RESEND PATCH V2 3/4] perf/x86/intel: drain PEBS buffer in event read

On 1/18/2018 4:49 AM, Jiri Olsa wrote: On Tue, Jan 16, 2018 at 01:49:13PM -0500, Liang, Kan wrote: On 1/11/2018 10:45 AM, Jiri Olsa wrote: On Thu, Jan 11, 2018 at 10:21:25AM -0500, Liang, Kan wrote: SNIP hum, but the PEBS drain is specific just for PERF_X86_EVENT_AUTO_RELOAD events

RE: [PATCH V4 12/15] perf hists browser: add parameter to disable lost event warning

> Hi, > > On Mon, Jan 15, 2018 at 12:20:48PM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > For overwrite mode, the ringbuffer will be paused. The event lost is > > expected. It needs a way to notify the browser not print the warning. > > > > It will be used

RE: [PATCH V4 12/15] perf hists browser: add parameter to disable lost event warning

> Hi, > > On Mon, Jan 15, 2018 at 12:20:48PM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > For overwrite mode, the ringbuffer will be paused. The event lost is > > expected. It needs a way to notify the browser not print the warning. > > > > It will be used later for perf top to

Re: [RESEND PATCH V2 3/4] perf/x86/intel: drain PEBS buffer in event read

On 1/11/2018 10:45 AM, Jiri Olsa wrote: On Thu, Jan 11, 2018 at 10:21:25AM -0500, Liang, Kan wrote: SNIP hum, but the PEBS drain is specific just for PERF_X86_EVENT_AUTO_RELOAD events, right? Accurately, PEBS drain is specific for PERF_X86_EVENT_FREERUNNING here

Re: [RESEND PATCH V2 3/4] perf/x86/intel: drain PEBS buffer in event read

On 1/11/2018 10:45 AM, Jiri Olsa wrote: On Thu, Jan 11, 2018 at 10:21:25AM -0500, Liang, Kan wrote: SNIP hum, but the PEBS drain is specific just for PERF_X86_EVENT_AUTO_RELOAD events, right? Accurately, PEBS drain is specific for PERF_X86_EVENT_FREERUNNING here

RE: [PATCH V4 02/15] perf mmap: introduce perf_mmap__read_init()

> On Mon, Jan 15, 2018 at 12:20:38PM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > The perf record has specific codes to calculate the ringbuffer position > > for both overwrite and non-overwrite mode. Now, only perf record > > supports both modes. The perf

RE: [PATCH V4 02/15] perf mmap: introduce perf_mmap__read_init()

> On Mon, Jan 15, 2018 at 12:20:38PM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > The perf record has specific codes to calculate the ringbuffer position > > for both overwrite and non-overwrite mode. Now, only perf record > > supports both modes. The perf top will support both

RE: [PATCH V4 5/8] perf/x86/intel/uncore: add infrastructure for free running counter

> On Thu, 2 Nov 2017, kan.li...@intel.com wrote: > > > From: Kan Liang > > > > The free running counter is read-only and always active. Current generic > > uncore code does not support this kind of counters. > > > > The free running counter is read-only. It cannot be

RE: [PATCH V4 5/8] perf/x86/intel/uncore: add infrastructure for free running counter

> On Thu, 2 Nov 2017, kan.li...@intel.com wrote: > > > From: Kan Liang > > > > The free running counter is read-only and always active. Current generic > > uncore code does not support this kind of counters. > > > > The free running counter is read-only. It cannot be enable/disable in > >

RE: [PATCH V3 08/12] perf top: check per event overwrite term

> > On Thu, Jan 11, 2018 at 09:29:21PM +, Liang, Kan wrote: > > > > On Thu, Dec 21, 2017 at 10:08:50AM -0800, kan.li...@intel.com wrote: > > > > > From: Kan Liang <kan.li...@intel.com> > > > > > > > > > > Per event o

RE: [PATCH V3 08/12] perf top: check per event overwrite term

> > On Thu, Jan 11, 2018 at 09:29:21PM +, Liang, Kan wrote: > > > > On Thu, Dec 21, 2017 at 10:08:50AM -0800, kan.li...@intel.com wrote: > > > > > From: Kan Liang > > > > > > > > > > Per event overwrite term is not forbidden in

RE: [PATCH V3 08/12] perf top: check per event overwrite term

> On Thu, Jan 11, 2018 at 09:29:21PM +0000, Liang, Kan wrote: > > > On Thu, Dec 21, 2017 at 10:08:50AM -0800, kan.li...@intel.com wrote: > > > > From: Kan Liang <kan.li...@intel.com> > > > > > > > > Per event overwrite term is not forbidden

RE: [PATCH V3 08/12] perf top: check per event overwrite term

> On Thu, Jan 11, 2018 at 09:29:21PM +0000, Liang, Kan wrote: > > > On Thu, Dec 21, 2017 at 10:08:50AM -0800, kan.li...@intel.com wrote: > > > > From: Kan Liang > > > > > > > > Per event overwrite term is not forbidden in perf top, which can >

RE: [PATCH V3 11/12] perf top: switch default mode to overwrite mode

> On Thu, Dec 21, 2017 at 10:08:53AM -0800, kan.li...@intel.com wrote: > > SNIP > > > .max_stack = sysctl_perf_event_max_stack, > > .sym_pcnt_filter = 5, > > diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c > > index

RE: [PATCH V3 11/12] perf top: switch default mode to overwrite mode

> On Thu, Dec 21, 2017 at 10:08:53AM -0800, kan.li...@intel.com wrote: > > SNIP > > > .max_stack = sysctl_perf_event_max_stack, > > .sym_pcnt_filter = 5, > > diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c > > index

RE: [PATCH V3 11/12] perf top: switch default mode to overwrite mode

> SNIP > > > .max_stack = sysctl_perf_event_max_stack, > > .sym_pcnt_filter = 5, > > diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c > > index 68146f4..56023e4 100644 > > --- a/tools/perf/ui/browsers/hists.c > > +++

RE: [PATCH V3 11/12] perf top: switch default mode to overwrite mode

> SNIP > > > .max_stack = sysctl_perf_event_max_stack, > > .sym_pcnt_filter = 5, > > diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c > > index 68146f4..56023e4 100644 > > --- a/tools/perf/ui/browsers/hists.c > > +++

RE: [PATCH V3 10/12] perf top: add overwrite fall back

> On Thu, Dec 21, 2017 at 10:08:52AM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Switch to non-overwrite mode if kernel doesnot support overwrite > > ringbuffer. > > > > It's only effect when overwrite mode is supported. > > No change to current behavior. >

RE: [PATCH V3 10/12] perf top: add overwrite fall back

> On Thu, Dec 21, 2017 at 10:08:52AM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Switch to non-overwrite mode if kernel doesnot support overwrite > > ringbuffer. > > > > It's only effect when overwrite mode is supported. > > No change to current behavior. > > > > Signed-off-by:

RE: [PATCH V3 08/12] perf top: check per event overwrite term

> On Thu, Dec 21, 2017 at 10:08:50AM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Per event overwrite term is not forbidden in perf top, which can bring > > problems. Because perf top only support non-overwrite mode. > > > > Check and forbid inconsistent per

RE: [PATCH V3 08/12] perf top: check per event overwrite term

> On Thu, Dec 21, 2017 at 10:08:50AM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Per event overwrite term is not forbidden in perf top, which can bring > > problems. Because perf top only support non-overwrite mode. > > > > Check and forbid inconsistent per event overwrite term

RE: [PATCH V3 07/12] perf mmap: discard legacy interface for mmap read

> On Thu, Dec 21, 2017 at 10:08:49AM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Discards perf_mmap__read_backward and perf_mmap__read_catchup. > No tools > > use them. > > > > There are tools still use perf_mmap__read_forward. Keep it, but add > > comments

RE: [PATCH V3 07/12] perf mmap: discard legacy interface for mmap read

> On Thu, Dec 21, 2017 at 10:08:49AM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Discards perf_mmap__read_backward and perf_mmap__read_catchup. > No tools > > use them. > > > > There are tools still use perf_mmap__read_forward. Keep it, but add > > comments to point to the new

RE: [PATCH V3 04/12] perf mmap: introduce perf_mmap__read_done

> On Thu, Dec 21, 2017 at 10:08:46AM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > The direction of overwrite mode is backward. The last mmap__read_event > > will set tail to map->prev. Need to correct the map->prev to head which > > is the end of next read. >

RE: [PATCH V3 04/12] perf mmap: introduce perf_mmap__read_done

> On Thu, Dec 21, 2017 at 10:08:46AM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > The direction of overwrite mode is backward. The last mmap__read_event > > will set tail to map->prev. Need to correct the map->prev to head which > > is the end of next read. > > > > It will be

RE: [PATCH V3 03/12] perf mmap: discard 'prev' in perf_mmap__read

> On Thu, Dec 21, 2017 at 10:08:45AM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > 'start' and 'prev' are duplicate in perf_mmap__read() > > > > Use 'map->prev' to replace 'start' in perf_mmap__read_*(). > > > > Suggested-by: Wang Nan > >

RE: [PATCH V3 03/12] perf mmap: discard 'prev' in perf_mmap__read

> On Thu, Dec 21, 2017 at 10:08:45AM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > 'start' and 'prev' are duplicate in perf_mmap__read() > > > > Use 'map->prev' to replace 'start' in perf_mmap__read_*(). > > > > Suggested-by: Wang Nan > > Signed-off-by: Kan Liang > > --- > >

RE: [PATCH V3 02/12] perf mmap: factor out function to find ringbuffer position

> On Thu, Dec 21, 2017 at 10:08:44AM -0800, kan.li...@intel.com wrote: > > SNIP > > > +/* > > + * Report the start and end of the available data in ringbuffer > > + */ > > +int perf_mmap__read_init(struct perf_mmap *map, bool overwrite, > > +u64 *start, u64 *end) > > { > >

RE: [PATCH V3 02/12] perf mmap: factor out function to find ringbuffer position

> On Thu, Dec 21, 2017 at 10:08:44AM -0800, kan.li...@intel.com wrote: > > SNIP > > > +/* > > + * Report the start and end of the available data in ringbuffer > > + */ > > +int perf_mmap__read_init(struct perf_mmap *map, bool overwrite, > > +u64 *start, u64 *end) > > { > >

Re: [RESEND PATCH V2 3/4] perf/x86/intel: drain PEBS buffer in event read

On 1/11/2018 6:10 AM, Jiri Olsa wrote: On Wed, Jan 10, 2018 at 09:31:56AM -0500, Liang, Kan wrote: On 1/10/2018 5:39 AM, Jiri Olsa wrote: On Mon, Jan 08, 2018 at 07:15:15AM -0800, kan.li...@intel.com wrote: From: Kan Liang <kan.li...@linux.intel.com> When the PEBS interrupt thr

Re: [RESEND PATCH V2 3/4] perf/x86/intel: drain PEBS buffer in event read

On 1/11/2018 6:10 AM, Jiri Olsa wrote: On Wed, Jan 10, 2018 at 09:31:56AM -0500, Liang, Kan wrote: On 1/10/2018 5:39 AM, Jiri Olsa wrote: On Mon, Jan 08, 2018 at 07:15:15AM -0800, kan.li...@intel.com wrote: From: Kan Liang When the PEBS interrupt threshold is larger than one

RE: [PATCH V3 04/12] perf mmap: introduce perf_mmap__read_done

> Hi, > > On Tue, Jan 09, 2018 at 03:12:28PM +0000, Liang, Kan wrote: > > > > > > > > > > > > > > Also I guess the current code might miss some events since the > head > > > can > >

RE: [PATCH V3 04/12] perf mmap: introduce perf_mmap__read_done

> Hi, > > On Tue, Jan 09, 2018 at 03:12:28PM +0000, Liang, Kan wrote: > > > > > > > > > > > > > > Also I guess the current code might miss some events since the > head > > > can > >

RE: [PATCH V3 02/12] perf mmap: factor out function to find ringbuffer position

> On Thu, Dec 21, 2017 at 10:08:44AM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > The perf record has specific codes to calculate the ringbuffer > > position for both overwrite and non-overwrite mode. > > The perf top will support both modes later. > > It is

RE: [PATCH V3 02/12] perf mmap: factor out function to find ringbuffer position

> On Thu, Dec 21, 2017 at 10:08:44AM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > The perf record has specific codes to calculate the ringbuffer > > position for both overwrite and non-overwrite mode. > > The perf top will support both modes later. > > It is useful to make the

Re: [RESEND PATCH V2 1/4] perf/x86/intel: fix event update for auto-reload

On 1/10/2018 5:22 AM, Jiri Olsa wrote: On Mon, Jan 08, 2018 at 07:15:13AM -0800, kan.li...@intel.com wrote: SNIP There is nothing need to do in x86_perf_event_set_period(). Because it is fixed period. The period_left is already adjusted. Signed-off-by: Kan Liang

Re: [RESEND PATCH V2 1/4] perf/x86/intel: fix event update for auto-reload

On 1/10/2018 5:22 AM, Jiri Olsa wrote: On Mon, Jan 08, 2018 at 07:15:13AM -0800, kan.li...@intel.com wrote: SNIP There is nothing need to do in x86_perf_event_set_period(). Because it is fixed period. The period_left is already adjusted. Signed-off-by: Kan Liang ---

<    1   2   3   4   5   6   7   8   9   10   >