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
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
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
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
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
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
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
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
!
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...@
!
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...@
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
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
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
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
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:
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:
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
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
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 @@
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 @@
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',
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
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
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
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.
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
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
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
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.
[
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.
[
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
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
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
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
> 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 +
> >
> 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
> 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
> 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
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
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
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,
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
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
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
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
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
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
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
> 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
> 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
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 +
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 +
> 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
> 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
> 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
> 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
> 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.
>
> 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.
>
>
> 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
>
> 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
> 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
> 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
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
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
> 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
> 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
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
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
> 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
> 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
> 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
> 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
> >
> > 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
> > 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
> 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
> 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
>
> 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
> 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
> 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
> > +++
> 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
> > +++
> 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.
>
> 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:
> 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
> 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
> 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
> 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
> 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.
>
> 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
> 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
> >
> 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
> > ---
> >
> 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)
> > {
> >
> 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)
> > {
> >
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
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
> 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
> >
> 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
> >
> 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
> 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
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
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
---
401 - 500 of 1326 matches
Mail list logo