RE: [PATCH V3] perf/x86/intel/uncore: remove nonexistent clockticks event for client uncore

> > > User observable change with the patch. > > clockticks event is removed from CBOX. User may need to change their > > script to use uncore_clock/clockticks/ instead. > > I don't think we can do that and break everyone's scripts. Have to keep the > old behavior, even though it is not ideal. >

RE: [PATCH V3] perf/x86/intel/uncore: remove nonexistent clockticks event for client uncore

> > > User observable change with the patch. > > clockticks event is removed from CBOX. User may need to change their > > script to use uncore_clock/clockticks/ instead. > > I don't think we can do that and break everyone's scripts. Have to keep the > old behavior, even though it is not ideal. >

RE: [PATCH] perf tools: set no branch type for dummy event in PT

> On Thu, Jun 29, 2017 at 03:50:29PM +0000, Liang, Kan wrote: > > > > > > > > > > On Thu, Jun 29, 2017 at 03:31:45PM +, Liang, Kan wrote: > > > > > > SNIP > > > > > > >

RE: [PATCH] perf tools: set no branch type for dummy event in PT

> On Thu, Jun 29, 2017 at 03:50:29PM +0000, Liang, Kan wrote: > > > > > > > > > > On Thu, Jun 29, 2017 at 03:31:45PM +, Liang, Kan wrote: > > > > > > SNIP > > > > > > >

RE: [PATCH] perf tools: set no branch type for dummy event in PT

> > On Thu, Jun 29, 2017 at 03:31:45PM +, Liang, Kan wrote: > > SNIP > > > > > static int intel_pt_recording_options(struct auxtrace_record *itr, > > > > struct perf_evlist *evlist, > > > >

RE: [PATCH] perf tools: set no branch type for dummy event in PT

> > On Thu, Jun 29, 2017 at 03:31:45PM +, Liang, Kan wrote: > > SNIP > > > > > static int intel_pt_recording_options(struct auxtrace_record *itr, > > > > struct perf_evlist *evlist, > > > >

RE: [PATCH] perf tools: set no branch type for dummy event in PT

> On Wed, Jun 28, 2017 at 10:31:53AM -0400, kan.li...@intel.com wrote: > > From: Kan Liang > > > > An earlier kernel patch allowed enabling PT and LBR at the same time > > on Goldmont. > > commit ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity > > if the

RE: [PATCH] perf tools: set no branch type for dummy event in PT

> On Wed, Jun 28, 2017 at 10:31:53AM -0400, kan.li...@intel.com wrote: > > From: Kan Liang > > > > An earlier kernel patch allowed enabling PT and LBR at the same time > > on Goldmont. > > commit ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity > > if the core supports it")

RE: [PATCH] kernel/watchdog: fix spurious hard lockups

> > > > From: Kan Liang > > > > > > > > Some users reported spurious NMI watchdog timeouts. > > > > > > > > We now have more and more systems where the Turbo range is wide > > > enough > > > > that the NMI watchdog expires faster than the soft watchdog timer > > > > that

RE: [PATCH] kernel/watchdog: fix spurious hard lockups

> > > > From: Kan Liang > > > > > > > > Some users reported spurious NMI watchdog timeouts. > > > > > > > > We now have more and more systems where the Turbo range is wide > > > enough > > > > that the NMI watchdog expires faster than the soft watchdog timer > > > > that updates the interrupt

RE: [PATCH] kernel/watchdog: fix spurious hard lockups

> > From: Kan Liang > > > > Some users reported spurious NMI watchdog timeouts. > > > > We now have more and more systems where the Turbo range is wide > enough > > that the NMI watchdog expires faster than the soft watchdog timer that > > updates the interrupt tick the NMI

RE: [PATCH] kernel/watchdog: fix spurious hard lockups

> > From: Kan Liang > > > > Some users reported spurious NMI watchdog timeouts. > > > > We now have more and more systems where the Turbo range is wide > enough > > that the NMI watchdog expires faster than the soft watchdog timer that > > updates the interrupt tick the NMI watchdog relies on. >

RE: [PATCH V2] kernel/watchdog: fix spurious hard lockups

> On Mon, Jun 26, 2017 at 04:19:27PM -0400, Don Zickus wrote: > > On Fri, Jun 23, 2017 at 11:50:25PM +0200, Thomas Gleixner wrote: > > > On Fri, 23 Jun 2017, Don Zickus wrote: > > > > Hmm, all this work for a temp fix. Kan, how much longer until the > > > > real fix of having perf count the

RE: [PATCH V2] kernel/watchdog: fix spurious hard lockups

> On Mon, Jun 26, 2017 at 04:19:27PM -0400, Don Zickus wrote: > > On Fri, Jun 23, 2017 at 11:50:25PM +0200, Thomas Gleixner wrote: > > > On Fri, 23 Jun 2017, Don Zickus wrote: > > > > Hmm, all this work for a temp fix. Kan, how much longer until the > > > > real fix of having perf count the

RE: [PATCH V2 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter

Hi all, Any comments for the series? We had some users (from both client and server) reported spurious NMI watchdog timeouts issue. Now, there is a proposed workaround fix from tglx. We are testing it. However, this patch series is believed to be a real fix for the issue. It's better that the

RE: [PATCH V2 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter

Hi all, Any comments for the series? We had some users (from both client and server) reported spurious NMI watchdog timeouts issue. Now, there is a proposed workaround fix from tglx. We are testing it. However, this patch series is believed to be a real fix for the issue. It's better that the

RE: [PATCH V2] kernel/watchdog: fix spurious hard lockups

> Subject: Re: [PATCH V2] kernel/watchdog: fix spurious hard lockups > > On Wed, Jun 21, 2017 at 11:53:57PM +0200, Thomas Gleixner wrote: > > On Wed, 21 Jun 2017, kan.li...@intel.com wrote: > > > We now have more and more systems where the Turbo range is wide > > > enough that the NMI watchdog

RE: [PATCH V2] kernel/watchdog: fix spurious hard lockups

> Subject: Re: [PATCH V2] kernel/watchdog: fix spurious hard lockups > > On Wed, Jun 21, 2017 at 11:53:57PM +0200, Thomas Gleixner wrote: > > On Wed, 21 Jun 2017, kan.li...@intel.com wrote: > > > We now have more and more systems where the Turbo range is wide > > > enough that the NMI watchdog

RE: [PATCH V2] kernel/watchdog: fix spurious hard lockups

> On Wed, 21 Jun 2017, kan.li...@intel.com wrote: > > > > #ifdef CONFIG_HARDLOCKUP_DETECTOR > > +/* > > + * The NMI watchdog relies on PERF_COUNT_HW_CPU_CYCLES event, > which > > + * can tick faster than the measured CPU Frequency due to Turbo mode. > > + * That can lead to spurious timeouts. >

RE: [PATCH V2] kernel/watchdog: fix spurious hard lockups

> On Wed, 21 Jun 2017, kan.li...@intel.com wrote: > > > > #ifdef CONFIG_HARDLOCKUP_DETECTOR > > +/* > > + * The NMI watchdog relies on PERF_COUNT_HW_CPU_CYCLES event, > which > > + * can tick faster than the measured CPU Frequency due to Turbo mode. > > + * That can lead to spurious timeouts. >

RE: [PATCH] kernel/watchdog: fix spurious hard lockups

. > On Wed, Jun 21, 2017 at 12:40:28PM +0000, Liang, Kan wrote: > > > > > > > > > > The right fix for mainline can be found here. > > > > perf/x86/intel: enable CPU ref_cycles for GP counter > > > > perf/x86/intel, > > >

RE: [PATCH] kernel/watchdog: fix spurious hard lockups

. > On Wed, Jun 21, 2017 at 12:40:28PM +0000, Liang, Kan wrote: > > > > > > > > > > The right fix for mainline can be found here. > > > > perf/x86/intel: enable CPU ref_cycles for GP counter > > > > perf/x86/intel, > > >

RE: [PATCH] kernel/watchdog: fix spurious hard lockups

> > On Tue, Jun 20, 2017 at 02:33:09PM -0700, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Some users reported spurious NMI watchdog timeouts. > > > > We now have more and more systems where the Turbo range is wide > enough > > that the NMI watchdog expires faster

RE: [PATCH] kernel/watchdog: fix spurious hard lockups

> > On Tue, Jun 20, 2017 at 02:33:09PM -0700, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Some users reported spurious NMI watchdog timeouts. > > > > We now have more and more systems where the Turbo range is wide > enough > > that the NMI watchdog expires faster than the soft

RE: [PATCH] kernel/watchdog: fix spurious hard lockups

> > > > The right fix for mainline can be found here. > > perf/x86/intel: enable CPU ref_cycles for GP counter perf/x86/intel, > > watchdog: Switch NMI watchdog to ref cycles on x86 > > https://patchwork.kernel.org/patch/9779087/ > > https://patchwork.kernel.org/patch/9779089/ > > Presumably the

RE: [PATCH] kernel/watchdog: fix spurious hard lockups

> > > > The right fix for mainline can be found here. > > perf/x86/intel: enable CPU ref_cycles for GP counter perf/x86/intel, > > watchdog: Switch NMI watchdog to ref cycles on x86 > > https://patchwork.kernel.org/patch/9779087/ > > https://patchwork.kernel.org/patch/9779089/ > > Presumably the

RE: [PATCH V2 0/2] measure SMI cost (user)

Hi Arnaldo and Jirka, Ping. Any comments for the patch? Thanks, Kan > Subject: RE: [PATCH V2 0/2] measure SMI cost (user) > > Hi Jirka, > > Have you got a chance to try the code? > Are you OK with the patch? > > Thanks, > Kan > > > > > Em Fri, Ju

RE: [PATCH V2 0/2] measure SMI cost (user)

Hi Arnaldo and Jirka, Ping. Any comments for the patch? Thanks, Kan > Subject: RE: [PATCH V2 0/2] measure SMI cost (user) > > Hi Jirka, > > Have you got a chance to try the code? > Are you OK with the patch? > > Thanks, > Kan > > > > > Em Fri, Ju

RE: [PATCH 2/5] perf/x86: add PERF_SAMPLE_SKID_IP support for X86 PEBS

> On Thu, Jun 15, 2017 at 8:40 AM, Liang, Kan <kan.li...@intel.com> wrote: > > > > > >> This patch adds support for SKID_IP to Intel x86 processors in PEBS > >> mode. In that case, the off-by-1 IP from PEBS is returned in the SKID_IP > field. > >

RE: [PATCH 2/5] perf/x86: add PERF_SAMPLE_SKID_IP support for X86 PEBS

> On Thu, Jun 15, 2017 at 8:40 AM, Liang, Kan wrote: > > > > > >> This patch adds support for SKID_IP to Intel x86 processors in PEBS > >> mode. In that case, the off-by-1 IP from PEBS is returned in the SKID_IP > field. > > > > It looks we can

RE: [PATCH 2/5] perf/x86: add PERF_SAMPLE_SKID_IP support for X86 PEBS

> This patch adds support for SKID_IP to Intel x86 processors in PEBS mode. In > that case, the off-by-1 IP from PEBS is returned in the SKID_IP field. It looks we can only get different skid_ip and ip with :pp event (attr.precise = 2). With the :p event (attr.precise = 1), the skid_ip and ip

RE: [PATCH 2/5] perf/x86: add PERF_SAMPLE_SKID_IP support for X86 PEBS

> This patch adds support for SKID_IP to Intel x86 processors in PEBS mode. In > that case, the off-by-1 IP from PEBS is returned in the SKID_IP field. It looks we can only get different skid_ip and ip with :pp event (attr.precise = 2). With the :p event (attr.precise = 1), the skid_ip and ip

RE: [PATCH V2 0/2] measure SMI cost (user)

Hi Jirka, Have you got a chance to try the code? Are you OK with the patch? Thanks, Kan > > Em Fri, Jun 02, 2017 at 03:45:11PM +, Liang, Kan escreveu: > > > > On Mon, May 29, 2017 at 02:52:39PM +0200, Peter Zijlstra wrote: > > > > > On Mon, May 29, 2017 at

RE: [PATCH V2 0/2] measure SMI cost (user)

Hi Jirka, Have you got a chance to try the code? Are you OK with the patch? Thanks, Kan > > Em Fri, Jun 02, 2017 at 03:45:11PM +, Liang, Kan escreveu: > > > > On Mon, May 29, 2017 at 02:52:39PM +0200, Peter Zijlstra wrote: > > > > > On Mon, May 29, 2017 at

RE: [PATCH V2 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter

> > On Fri, Jun 09, 2017 at 10:28:02AM -0700, kan.li...@intel.com wrote: > > SNIP > > > + /* > > +* Correct the count number if applying ref_cycles replacement. > > +* There is a constant ratio between ref_cycles (event A) and > > +* ref_cycles replacement (event B). The delta

RE: [PATCH V2 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter

> > On Fri, Jun 09, 2017 at 10:28:02AM -0700, kan.li...@intel.com wrote: > > SNIP > > > + /* > > +* Correct the count number if applying ref_cycles replacement. > > +* There is a constant ratio between ref_cycles (event A) and > > +* ref_cycles replacement (event B). The delta

RE: [PATCH V2 2/2] perf/x86/intel, watchdog: Switch NMI watchdog to ref cycles on x86

> When you re-send these patches that got reverted earlier, you really > should add yourself to the sign-off list.. and if you were the original > author, you should have been there from the first... > Hmm? Andi was the original author. Sure, I will add my signature after him. Thanks, Kan >

RE: [PATCH V2 2/2] perf/x86/intel, watchdog: Switch NMI watchdog to ref cycles on x86

> When you re-send these patches that got reverted earlier, you really > should add yourself to the sign-off list.. and if you were the original > author, you should have been there from the first... > Hmm? Andi was the original author. Sure, I will add my signature after him. Thanks, Kan >

RE: [PATCH V2 0/2] measure SMI cost (user)

> > > > On Mon, May 29, 2017 at 02:52:39PM +0200, Peter Zijlstra wrote: > > > On Mon, May 29, 2017 at 02:46:37PM +0200, Jiri Olsa wrote: > > > > > > > for some reason I can't get single SMI count generated, is there a > > > > setup/bench that would provoke that? > > > > > > Not having SMIs is a

RE: [PATCH V2 0/2] measure SMI cost (user)

> > > > On Mon, May 29, 2017 at 02:52:39PM +0200, Peter Zijlstra wrote: > > > On Mon, May 29, 2017 at 02:46:37PM +0200, Jiri Olsa wrote: > > > > > > > for some reason I can't get single SMI count generated, is there a > > > > setup/bench that would provoke that? > > > > > > Not having SMIs is a

RE: [PATCH V2 0/2] measure SMI cost (user)

> > On Mon, May 29, 2017 at 02:52:39PM +0200, Peter Zijlstra wrote: > > On Mon, May 29, 2017 at 02:46:37PM +0200, Jiri Olsa wrote: > > > > > for some reason I can't get single SMI count generated, is there a > > > setup/bench that would provoke that? > > > > Not having SMIs is a good thing ;-) >

RE: [PATCH V2 0/2] measure SMI cost (user)

> > On Mon, May 29, 2017 at 02:52:39PM +0200, Peter Zijlstra wrote: > > On Mon, May 29, 2017 at 02:46:37PM +0200, Jiri Olsa wrote: > > > > > for some reason I can't get single SMI count generated, is there a > > > setup/bench that would provoke that? > > > > Not having SMIs is a good thing ;-) >

RE: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter

> > On Mon, May 22, 2017 at 12:23 PM, Peter Zijlstra <pet...@infradead.org> > wrote: > > On Mon, May 22, 2017 at 04:55:47PM +, Liang, Kan wrote: > >> > >> > >> > On Fri, May 19, 2017 at 10:06:21AM -0700, kan.li...@intel.com wrote: > >&g

RE: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter

> > On Mon, May 22, 2017 at 12:23 PM, Peter Zijlstra > wrote: > > On Mon, May 22, 2017 at 04:55:47PM +0000, Liang, Kan wrote: > >> > >> > >> > On Fri, May 19, 2017 at 10:06:21AM -0700, kan.li...@intel.com wrote: > >> > > diff --git a/ar

RE: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter

> On Mon, May 22, 2017 at 11:19:16AM +0200, Peter Zijlstra wrote: > > On Fri, May 19, 2017 at 10:06:21AM -0700, kan.li...@intel.com wrote: > > > @@ -934,6 +938,21 @@ int x86_schedule_events(struct cpu_hw_events > > > *cpuc, int n, int *assign) > > > > for (i = 0; i < n; i++) { > > >

RE: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter

> On Mon, May 22, 2017 at 11:19:16AM +0200, Peter Zijlstra wrote: > > On Fri, May 19, 2017 at 10:06:21AM -0700, kan.li...@intel.com wrote: > > > @@ -934,6 +938,21 @@ int x86_schedule_events(struct cpu_hw_events > > > *cpuc, int n, int *assign) > > > > for (i = 0; i < n; i++) { > > >

RE: [PATCH 2/2] perf/x86/intel, watchdog: Switch NMI watchdog to ref cycles on x86

> On Fri, May 19, 2017 at 10:06:22AM -0700, kan.li...@intel.com wrote: > > This patch was once merged, but reverted later. > > Because ref-cycles can not be used anymore when watchdog is enabled. > > The commit is 44530d588e142a96cf0cd345a7cb8911c4f88720 > > > > The patch 1/2 has extended the

RE: [PATCH 2/2] perf/x86/intel, watchdog: Switch NMI watchdog to ref cycles on x86

> On Fri, May 19, 2017 at 10:06:22AM -0700, kan.li...@intel.com wrote: > > This patch was once merged, but reverted later. > > Because ref-cycles can not be used anymore when watchdog is enabled. > > The commit is 44530d588e142a96cf0cd345a7cb8911c4f88720 > > > > The patch 1/2 has extended the

RE: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter

> On Fri, May 19, 2017 at 10:06:21AM -0700, kan.li...@intel.com wrote: > > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index > > 580b60f..e8b2326 100644 > > --- a/arch/x86/events/core.c > > +++ b/arch/x86/events/core.c > > @@ -101,6 +101,10 @@ u64 x86_perf_event_update(struct

RE: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter

> On Fri, May 19, 2017 at 10:06:21AM -0700, kan.li...@intel.com wrote: > > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index > > 580b60f..e8b2326 100644 > > --- a/arch/x86/events/core.c > > +++ b/arch/x86/events/core.c > > @@ -101,6 +101,10 @@ u64 x86_perf_event_update(struct

RE: [PATCH V7] perf/x86: add sysfs entry to freeze counter on SMI

Hi tglx, Are you OK with patch? Thanks, Kan > > From: Kan Liang > > Currently, the SMIs are visible to all performance counters. Because > many users want to measure everything including SMIs. But in some > cases, the SMI cycles should not be count. For example, to

RE: [PATCH V7] perf/x86: add sysfs entry to freeze counter on SMI

Hi tglx, Are you OK with patch? Thanks, Kan > > From: Kan Liang > > Currently, the SMIs are visible to all performance counters. Because > many users want to measure everything including SMIs. But in some > cases, the SMI cycles should not be count. For example, to calculate > the cost of

RE: [PATCH V5] perf/x86: add sysfs entry to freeze counter on SMI

> > > > > +static void flip_smm_bit(void *data) { > > > > + bool set = *(int *)data; > > data points to an unsigned long. So while this works on LE machines this is > still crap. I will change the code as below. +static void flip_smm_bit(void *data) +{ + unsigned long set =

RE: [PATCH V5] perf/x86: add sysfs entry to freeze counter on SMI

> > > > > +static void flip_smm_bit(void *data) { > > > > + bool set = *(int *)data; > > data points to an unsigned long. So while this works on LE machines this is > still crap. I will change the code as below. +static void flip_smm_bit(void *data) +{ + unsigned long set =

RE: [PATCH V5] perf/x86: add sysfs entry to freeze counter on SMI

Hi tglx, Are you OK with patch? Could I get your "acked-by"? Thanks, Kan > > > Ping. > Any comments for the patch? > > Thanks, > Kan > > > Subject: [PATCH V5] perf/x86: add sysfs entry to freeze counter on SMI > > > > From: Kan Liang > > > > Currently, the SMIs are

RE: [PATCH V5] perf/x86: add sysfs entry to freeze counter on SMI

Hi tglx, Are you OK with patch? Could I get your "acked-by"? Thanks, Kan > > > Ping. > Any comments for the patch? > > Thanks, > Kan > > > Subject: [PATCH V5] perf/x86: add sysfs entry to freeze counter on SMI > > > > From: Kan Liang > > > > Currently, the SMIs are visible to all

RE: [RFC 0/6] optimize ctx switch with rb-tree

Hi David, Is there any update about the patch series? We recently encountered another performance issue on KNL. I think the RB-tree solution also has benefits for it. Thanks, Kan > Subject: [RFC 0/6] optimize ctx switch with rb-tree > > Following the discussion in: >

RE: [RFC 0/6] optimize ctx switch with rb-tree

Hi David, Is there any update about the patch series? We recently encountered another performance issue on KNL. I think the RB-tree solution also has benefits for it. Thanks, Kan > Subject: [RFC 0/6] optimize ctx switch with rb-tree > > Following the discussion in: >

RE: [PATCH V5] perf/x86: add sysfs entry to freeze counter on SMI

Ping. Any comments for the patch? Thanks, Kan > Subject: [PATCH V5] perf/x86: add sysfs entry to freeze counter on SMI > > From: Kan Liang > > Currently, the SMIs are visible to all performance counters. Because many > users want to measure everything including SMIs. But

RE: [PATCH V5] perf/x86: add sysfs entry to freeze counter on SMI

Ping. Any comments for the patch? Thanks, Kan > Subject: [PATCH V5] perf/x86: add sysfs entry to freeze counter on SMI > > From: Kan Liang > > Currently, the SMIs are visible to all performance counters. Because many > users want to measure everything including SMIs. But in some cases, the

RE: [PATCH 0/3]measure SMI cost

> On Thu, Mar 23, 2017 at 11:25 AM, wrote: > > From: Kan Liang > > > > Currently, there is no way to measure the time cost in System > > management mode (SMM) by perf. > > > > Intel perfmon supports FREEZE_WHILE_SMM bit in IA32_DEBUGCTL. Once > it > >

RE: [PATCH 0/3]measure SMI cost

> On Thu, Mar 23, 2017 at 11:25 AM, wrote: > > From: Kan Liang > > > > Currently, there is no way to measure the time cost in System > > management mode (SMM) by perf. > > > > Intel perfmon supports FREEZE_WHILE_SMM bit in IA32_DEBUGCTL. Once > it > > sets, the PMU core counters will freeze

RE: [PATCH V4 1/2] x86/msr: expose msr_flip_bit function

> > -static inline int __flip_bit(u32 msr, u8 bit, bool set) > > +int msr_flip_bit(u32 msr, u8 bit, bool set) > > { > > struct msr m, m1; > > int err = -EINVAL; > > @@ -85,6 +85,7 @@ static inline int __flip_bit(u32 msr, u8 bit, bool > > set) > > > > return 1; > > } > >

RE: [PATCH V4 1/2] x86/msr: expose msr_flip_bit function

> > -static inline int __flip_bit(u32 msr, u8 bit, bool set) > > +int msr_flip_bit(u32 msr, u8 bit, bool set) > > { > > struct msr m, m1; > > int err = -EINVAL; > > @@ -85,6 +85,7 @@ static inline int __flip_bit(u32 msr, u8 bit, bool > > set) > > > > return 1; > > } > >

RE: [PATCH V3 1/2] x86/msr: add msr_set/clear_bit_on_cpu/cpus access functions

. > > msr_set/clear_bit() are not protected by anyhting. And in your call > > site this is invoked from fully preemptible context. What protects > > against context switch and interrupts fiddling with DEBUGMSR? > > And thinking more about that whole interface. It's just overkill. > > diff

RE: [PATCH V3 1/2] x86/msr: add msr_set/clear_bit_on_cpu/cpus access functions

. > > msr_set/clear_bit() are not protected by anyhting. And in your call > > site this is invoked from fully preemptible context. What protects > > against context switch and interrupts fiddling with DEBUGMSR? > > And thinking more about that whole interface. It's just overkill. > > diff

RE: [PATCH V3 2/2] perf/x86: add sysfs entry to freeze counter on SMI

> > On Mon, 27 Mar 2017, kan.li...@intel.com wrote: > > + > > + if (val) > > + msr_set_bit_on_cpus(cpu_possible_mask, > MSR_IA32_DEBUGCTLMSR, DEBUGCTLMSR_FREEZE_WHILE_SMM_BIT); > > + else > > + msr_clear_bit_on_cpus(cpu_possible_mask, > MSR_IA32_DEBUGCTLMSR, > >

RE: [PATCH V3 2/2] perf/x86: add sysfs entry to freeze counter on SMI

> > On Mon, 27 Mar 2017, kan.li...@intel.com wrote: > > + > > + if (val) > > + msr_set_bit_on_cpus(cpu_possible_mask, > MSR_IA32_DEBUGCTLMSR, DEBUGCTLMSR_FREEZE_WHILE_SMM_BIT); > > + else > > + msr_clear_bit_on_cpus(cpu_possible_mask, > MSR_IA32_DEBUGCTLMSR, > >

RE: [PATCH V2 1/2] x86/msr: add msr_set/clear_bit_on_cpu/cpus access functions

> > On Mon, Mar 27, 2017 at 08:47:37AM -0700, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Having msr_set/clear_bit on many cpus or given CPU can avoid extra > > unnecessory IPIs > > How does that happen? > My previous patch did a read-modify-write operation.

RE: [PATCH V2 1/2] x86/msr: add msr_set/clear_bit_on_cpu/cpus access functions

> > On Mon, Mar 27, 2017 at 08:47:37AM -0700, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Having msr_set/clear_bit on many cpus or given CPU can avoid extra > > unnecessory IPIs > > How does that happen? > My previous patch did a read-modify-write operation. Compared with the

RE: [PATCH 1/3] perf/x86: add sysfs entry to freeze counter on SMI

> On Thu, 23 Mar 2017, Peter Zijlstra wrote: > > On Thu, Mar 23, 2017 at 11:25:49AM -0700, kan.li...@intel.com wrote: > > > + for_each_possible_cpu(cpu) { > > > + rdmsrl_on_cpu(cpu, MSR_IA32_DEBUGCTLMSR, > ); > > > + if (val) > > > + wrmsrl_on_cpu(cpu,

RE: [PATCH 1/3] perf/x86: add sysfs entry to freeze counter on SMI

> On Thu, 23 Mar 2017, Peter Zijlstra wrote: > > On Thu, Mar 23, 2017 at 11:25:49AM -0700, kan.li...@intel.com wrote: > > > + for_each_possible_cpu(cpu) { > > > + rdmsrl_on_cpu(cpu, MSR_IA32_DEBUGCTLMSR, > ); > > > + if (val) > > > + wrmsrl_on_cpu(cpu,

RE: [PATCH 0/3]measure SMI cost

> > > > > A new --smi-cost mode in perf stat is implemented to measure the > > > > SMI cost by calculating cycles and aperf results. In practice, the > > > > percentages of SMI cycles should be more useful than absolute value. > > > > > > That's only true for performance oriented analysis, but

RE: [PATCH 0/3]measure SMI cost

> > > > > A new --smi-cost mode in perf stat is implemented to measure the > > > > SMI cost by calculating cycles and aperf results. In practice, the > > > > percentages of SMI cycles should be more useful than absolute value. > > > > > > That's only true for performance oriented analysis, but

RE: [PATCH 1/3] perf/x86: add sysfs entry to freeze counter on SMI

> On Thu, Mar 23, 2017 at 11:25:49AM -0700, kan.li...@intel.com wrote: > > From: Kan Liang > > > > When setting FREEZE_WHILE_SMM bit in IA32_DEBUGCTL, all > performance > > counters will be effected. There is no way to do per-counter freeze on > > smi. So it should not use

RE: [PATCH 1/3] perf/x86: add sysfs entry to freeze counter on SMI

> On Thu, Mar 23, 2017 at 11:25:49AM -0700, kan.li...@intel.com wrote: > > From: Kan Liang > > > > When setting FREEZE_WHILE_SMM bit in IA32_DEBUGCTL, all > performance > > counters will be effected. There is no way to do per-counter freeze on > > smi. So it should not use the per-event interface

RE: [PATCH V2] x86, perf: Add Top Down events to Intel Goldmont

Ping. Any comments for this patch? Thanks, Kan > > From: Kan Liang > > Goldmont supports full Top Down level 1 metrics (FrontendBound, > Retiring, Backend Bound and Bad Speculation). > It has 3 wide pipeline. > > Signed-off-by: Kan Liang > --- > >

RE: [PATCH V2] x86, perf: Add Top Down events to Intel Goldmont

Ping. Any comments for this patch? Thanks, Kan > > From: Kan Liang > > Goldmont supports full Top Down level 1 metrics (FrontendBound, > Retiring, Backend Bound and Bad Speculation). > It has 3 wide pipeline. > > Signed-off-by: Kan Liang > --- > > Changes since V1: > - Change event list

RE: [PATCH] perf/x86: fix event counter update issue

> > On Wed, 22 Feb 2017, Liang, Kan wrote: > > > > So from what I understand, the issue is if we have an architecture > > > with full- width counters and we trigger a x86_perf_event_update() > > > when bit > > > 47 is set? > > > > No. I

RE: [PATCH] perf/x86: fix event counter update issue

> > On Wed, 22 Feb 2017, Liang, Kan wrote: > > > > So from what I understand, the issue is if we have an architecture > > > with full- width counters and we trigger a x86_perf_event_update() > > > when bit > > > 47 is set? > > > > No. I

RE: [PATCH] perf/x86: fix event counter update issue

> > On Mon, 5 Dec 2016, Peter Zijlstra wrote: > > > --- > > Subject: perf,x86: Fix full width counter, counter overflow > > Date: Tue, 29 Nov 2016 20:33:28 + > > > > Lukasz reported that perf stat counters overflow is broken on KNL/SLM. > > > > Both these parts have full_width_write set,

RE: [PATCH] perf/x86: fix event counter update issue

> > On Mon, 5 Dec 2016, Peter Zijlstra wrote: > > > --- > > Subject: perf,x86: Fix full width counter, counter overflow > > Date: Tue, 29 Nov 2016 20:33:28 + > > > > Lukasz reported that perf stat counters overflow is broken on KNL/SLM. > > > > Both these parts have full_width_write set,

RE: [PATCH 2/2] perf,core: use parent avg sample period as child initial period

> > On Wed, Jan 18, 2017 at 08:21:02AM -0500, kan.li...@intel.com wrote: > > From: Kan Liang > > > > perf brings additional overhead when monitoring the task which > > frequently generates child task. > > > > When inheriting a event from parent task to child task, the > >

RE: [PATCH 2/2] perf,core: use parent avg sample period as child initial period

> > On Wed, Jan 18, 2017 at 08:21:02AM -0500, kan.li...@intel.com wrote: > > From: Kan Liang > > > > perf brings additional overhead when monitoring the task which > > frequently generates child task. > > > > When inheriting a event from parent task to child task, the > > sample_period of

RE: [RFC] perf/x86/intel/uncore: pmu->type->single_fixed question

> > > On Mon, Dec 12, 2016 at 02:49:03PM +0000, Liang, Kan wrote: > > > > > > > > > > I really would prefer to move the thing to its own PMU. > > > > > > The patch as below creates a new PMU to fix the issue. > >

RE: [RFC] perf/x86/intel/uncore: pmu->type->single_fixed question

> > > On Mon, Dec 12, 2016 at 02:49:03PM +0000, Liang, Kan wrote: > > > > > > > > > > I really would prefer to move the thing to its own PMU. > > > > > > The patch as below creates a new PMU to fix the issue. > >

RE: [RFC 3/6] perf/core: use rb-tree to sched in event groups

> On Wed, Jan 11, 2017 at 08:31:11PM +0000, Liang, Kan wrote: > > > > Kan, in your per-cpu event list patch you mentioned that you saw a > > > large overhead in perf_iterate_ctx() when skipping events for other > CPUs. > > > Which caller

RE: [RFC 3/6] perf/core: use rb-tree to sched in event groups

> On Wed, Jan 11, 2017 at 08:31:11PM +0000, Liang, Kan wrote: > > > > Kan, in your per-cpu event list patch you mentioned that you saw a > > > large overhead in perf_iterate_ctx() when skipping events for other > CPUs. > > > Which caller

RE: [RFC 3/6] perf/core: use rb-tree to sched in event groups

. > > Kan, in your per-cpu event list patch you mentioned that you saw a large > overhead in perf_iterate_ctx() when skipping events for other CPUs. > Which callers of perf_iterate_ctx() specifically was that problematic for? Do > those callers only care about the *active* events, for example?

RE: [RFC 3/6] perf/core: use rb-tree to sched in event groups

. > > Kan, in your per-cpu event list patch you mentioned that you saw a large > overhead in perf_iterate_ctx() when skipping events for other CPUs. > Which callers of perf_iterate_ctx() specifically was that problematic for? Do > those callers only care about the *active* events, for example?

RE: [PATCH V3 0/6] export perf overheads information (kernel)

Hi Peter, Any comments? Thanks, Kan > Subject: RE: [PATCH V3 0/6] export perf overheads information (kernel) > > > Ping. > Any comments for the series? > > Thanks, > Kan > > > Subject: [PATCH V3 0/6] export perf overheads information (kernel) > > > > From: Kan Liang >

RE: [PATCH V3 0/6] export perf overheads information (kernel)

Hi Peter, Any comments? Thanks, Kan > Subject: RE: [PATCH V3 0/6] export perf overheads information (kernel) > > > Ping. > Any comments for the series? > > Thanks, > Kan > > > Subject: [PATCH V3 0/6] export perf overheads information (kernel) > > > > From: Kan Liang > > > > This series

RE: [RFC] perf/x86/intel/uncore: pmu->type->single_fixed question

> On Mon, Dec 12, 2016 at 02:49:03PM +0000, Liang, Kan wrote: > > > > > > > I really would prefer to move the thing to its own PMU. > > > > The patch as below creates a new PMU to fix the issue. > > > > Jirka, could you please try the pa

RE: [RFC] perf/x86/intel/uncore: pmu->type->single_fixed question

> On Mon, Dec 12, 2016 at 02:49:03PM +0000, Liang, Kan wrote: > > > > > > > I really would prefer to move the thing to its own PMU. > > > > The patch as below creates a new PMU to fix the issue. > > > > Jirka, could you please try the pa

RE: [PATCH] perf diff: bug fix, donot overwrite valid build id

Hi Arnaldo, Ping Are you OK with the fix? Thanks, Kan > > From: Kan Liang > > Fixes a perf diff regression issue which was introduced by commit > 5baecbcd9c9a ("perf symbols: we can now read separate debug-info files > based on a build ID") > > The binary name could be

RE: [PATCH] perf diff: bug fix, donot overwrite valid build id

Hi Arnaldo, Ping Are you OK with the fix? Thanks, Kan > > From: Kan Liang > > Fixes a perf diff regression issue which was introduced by commit > 5baecbcd9c9a ("perf symbols: we can now read separate debug-info files > based on a build ID") > > The binary name could be same when perf diff

RE: [PATCH V3 0/6] export perf overheads information (kernel)

Ping. Any comments for the series? Thanks, Kan > Subject: [PATCH V3 0/6] export perf overheads information (kernel) > > From: Kan Liang > > This series only include the kernel related patches. > > Profiling brings additional overhead. High overhead may impacts the >

RE: [PATCH V3 0/6] export perf overheads information (kernel)

Ping. Any comments for the series? Thanks, Kan > Subject: [PATCH V3 0/6] export perf overheads information (kernel) > > From: Kan Liang > > This series only include the kernel related patches. > > Profiling brings additional overhead. High overhead may impacts the > behavior of the

RE: [PATCH] perf tools: ignore zombie process for user profile

. > Em Wed, Dec 14, 2016 at 06:26:02PM +0000, Liang, Kan escreveu: > > > On Wed, Dec 14, 2016 at 12:48:05PM -0500, kan.li...@intel.com wrote: > > > > From: Kan Liang <kan.li...@intel.com> Zombie process is dead > > > > process. It is meaningless to

RE: [PATCH] perf tools: ignore zombie process for user profile

. > Em Wed, Dec 14, 2016 at 06:26:02PM +0000, Liang, Kan escreveu: > > > On Wed, Dec 14, 2016 at 12:48:05PM -0500, kan.li...@intel.com wrote: > > > > From: Kan Liang Zombie process is dead > > > > process. It is meaningless to profile it. > > >

<    3   4   5   6   7   8   9   10   11   12   >