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

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, there is no way to get exact auto-reload times and value needed for event update

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

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, there is no way to get exact auto-reload times and value needed for event update unless flush the PEBS buffer.

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

> > > > > > > > > > Also I guess the current code might miss some events since the head > can > > > be > > > > > different between _read_init() and _read_done(), no? > > > > > > > > > > > > > The overwrite mode requires the ring buffer to be paused during > > > processing. > > > > The head is

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

> > > > > > > > > > Also I guess the current code might miss some events since the head > can > > > be > > > > > different between _read_init() and _read_done(), no? > > > > > > > > > > > > > The overwrite mode requires the ring buffer to be paused during > > > processing. > > > > The head is

RE: [PATCH V2] perf script: add script to profile and resolve physical mem type

> Dear Kan, > > On Wed, Jan 3, 2018 at 9:20 PM, Liang, Kan <kan.li...@intel.com> wrote: > > Hi Stephane and Andi, > > > > Could you please review the script? > > > > If it's OK for you, could you please Ack/Review this? > > > > Thanks, &

RE: [PATCH V2] perf script: add script to profile and resolve physical mem type

> Dear Kan, > > On Wed, Jan 3, 2018 at 9:20 PM, Liang, Kan wrote: > > Hi Stephane and Andi, > > > > Could you please review the script? > > > > If it's OK for you, could you please Ack/Review this? > > > > Thanks, > > Kan > > >

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

> Hi Kan, > > On Wed, Jan 03, 2018 at 02:15:38PM +0000, Liang, Kan wrote: > > > Hello, > > > > > > On Thu, Dec 21, 2017 at 10:08:46AM -0800, kan.li...@intel.com wrote: > > > > From: Kan Liang <kan.li...@intel.com> > > >

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

> Hi Kan, > > On Wed, Jan 03, 2018 at 02:15:38PM +0000, Liang, Kan wrote: > > > Hello, > > > > > > On Thu, Dec 21, 2017 at 10:08:46AM -0800, kan.li...@intel.com wrote: > > > > From: Kan Liang > > > > > > > >

RE: [PATCH V2] perf script: add script to profile and resolve physical mem type

Hi Stephane and Andi, Could you please review the script? If it's OK for you, could you please Ack/Review this? Thanks, Kan > > From: Kan Liang > > There could be different types of memory in the system. E.g normal > System Memory, Persistent Memory. To understand how

RE: [PATCH V2] perf script: add script to profile and resolve physical mem type

Hi Stephane and Andi, Could you please review the script? If it's OK for you, could you please Ack/Review this? Thanks, Kan > > From: Kan Liang > > There could be different types of memory in the system. E.g normal > System Memory, Persistent Memory. To understand how the workload maps > to

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

> Hello, > > 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

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

> Hello, > > 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. > > Why

Re: [PATCH V2 4/4] perf/x86: fix: disable userspace RDPMC usage for large PEBS

On 12/20/2017 4:41 PM, Andi Kleen wrote: On Wed, Dec 20, 2017 at 11:42:51AM -0800, kan.li...@linux.intel.com wrote: From: Kan Liang The userspace RDPMC usage never works for large PEBS since the large PEBS is introduced by commit b8241d20699e ("perf/x86/intel:

Re: [PATCH V2 4/4] perf/x86: fix: disable userspace RDPMC usage for large PEBS

On 12/20/2017 4:41 PM, Andi Kleen wrote: On Wed, Dec 20, 2017 at 11:42:51AM -0800, kan.li...@linux.intel.com wrote: From: Kan Liang The userspace RDPMC usage never works for large PEBS since the large PEBS is introduced by commit b8241d20699e ("perf/x86/intel: Implement batched PEBS

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

On 12/19/2017 5:07 PM, Peter Zijlstra wrote: On Tue, Dec 19, 2017 at 03:08:58PM -0500, Liang, Kan wrote: This all looks very wrong... In auto reload we should never call intel_pmu_save_and_restore() in the first place I think. Things like x86_perf_event_update() and x86_perf_event_set_period

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

On 12/19/2017 5:07 PM, Peter Zijlstra wrote: On Tue, Dec 19, 2017 at 03:08:58PM -0500, Liang, Kan wrote: This all looks very wrong... In auto reload we should never call intel_pmu_save_and_restore() in the first place I think. Things like x86_perf_event_update() and x86_perf_event_set_period

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

On 12/19/2017 3:08 PM, Liang, Kan wrote: On 12/19/2017 1:58 PM, Peter Zijlstra wrote: On Mon, Dec 18, 2017 at 03:34:49AM -0800, kan.li...@linux.intel.com wrote:   arch/x86/events/core.c | 14 ++   arch/x86/events/intel/ds.c |  8 +++-   2 files changed, 21 insertions

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

On 12/19/2017 3:08 PM, Liang, Kan wrote: On 12/19/2017 1:58 PM, Peter Zijlstra wrote: On Mon, Dec 18, 2017 at 03:34:49AM -0800, kan.li...@linux.intel.com wrote:   arch/x86/events/core.c | 14 ++   arch/x86/events/intel/ds.c |  8 +++-   2 files changed, 21 insertions

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

On 12/19/2017 2:02 PM, Peter Zijlstra wrote: On Mon, Dec 18, 2017 at 03:34:51AM -0800, kan.li...@linux.intel.com wrote: --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -926,6 +926,16 @@ void intel_pmu_pebs_del(struct perf_event *event) pebs_update_state(needed_cb,

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

On 12/19/2017 2:02 PM, Peter Zijlstra wrote: On Mon, Dec 18, 2017 at 03:34:51AM -0800, kan.li...@linux.intel.com wrote: --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -926,6 +926,16 @@ void intel_pmu_pebs_del(struct perf_event *event) pebs_update_state(needed_cb,

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

On 12/19/2017 1:58 PM, Peter Zijlstra wrote: On Mon, Dec 18, 2017 at 03:34:49AM -0800, kan.li...@linux.intel.com wrote: arch/x86/events/core.c | 14 ++ arch/x86/events/intel/ds.c | 8 +++- 2 files changed, 21 insertions(+), 1 deletion(-) diff --git

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

On 12/19/2017 1:58 PM, Peter Zijlstra wrote: On Mon, Dec 18, 2017 at 03:34:49AM -0800, kan.li...@linux.intel.com wrote: arch/x86/events/core.c | 14 ++ arch/x86/events/intel/ds.c | 8 +++- 2 files changed, 21 insertions(+), 1 deletion(-) diff --git

RE: [PATCH V2 2/8] perf tools: rewrite perf mmap read for overwrite

> >>> +int perf_mmap__read_catchup(struct perf_mmap *map, > >>> + bool overwrite, > >>> + u64 *start, u64 *end, > >>> + unsigned long *size) > >>>{ > >>> - u64 head; > >>> + u64 head = perf_mmap__read_head(map); > >>> + u64 old =

RE: [PATCH V2 2/8] perf tools: rewrite perf mmap read for overwrite

> >>> +int perf_mmap__read_catchup(struct perf_mmap *map, > >>> + bool overwrite, > >>> + u64 *start, u64 *end, > >>> + unsigned long *size) > >>>{ > >>> - u64 head; > >>> + u64 head = perf_mmap__read_head(map); > >>> + u64 old =

RE: [PATCH V2 6/8] perf top: add overwrite fall back

> > On 2017/12/7 7:33, 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 V2 6/8] perf top: add overwrite fall back

> > On 2017/12/7 7:33, 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: Kan Liang > > --- >

RE: [PATCH V2 2/8] perf tools: rewrite perf mmap read for overwrite

> > -union perf_event *perf_mmap__read_backward(struct perf_mmap *map) > > +union perf_event *perf_mmap__read_backward(struct perf_mmap *map, > > + u64 *start, u64 end) > > { > > - u64 head, end; > > - u64 start = map->prev; > > - > > - /* > > -*

RE: [PATCH V2 2/8] perf tools: rewrite perf mmap read for overwrite

> > -union perf_event *perf_mmap__read_backward(struct perf_mmap *map) > > +union perf_event *perf_mmap__read_backward(struct perf_mmap *map, > > + u64 *start, u64 end) > > { > > - u64 head, end; > > - u64 start = map->prev; > > - > > - /* > > -*

RE: [PATCH V4 1/8] perf/x86/intel/uncore: customized event_read for client IMC uncore

Hi Thomas, Did you get a chance to review the patch series? Thanks, Kan > > On Fri, 17 Nov 2017, Liang, Kan wrote: > > > Hi Thomas, > > > > Any comments for this patch series? > > it's on my todo list.

RE: [PATCH V4 1/8] perf/x86/intel/uncore: customized event_read for client IMC uncore

Hi Thomas, Did you get a chance to review the patch series? Thanks, Kan > > On Fri, 17 Nov 2017, Liang, Kan wrote: > > > Hi Thomas, > > > > Any comments for this patch series? > > it's on my todo list.

RE: [PATCH V2] perf script: add script to profile and resolve physical mem type

Hi Arnaldo, Ping. Any comments for the script? Thanks, Kan > > > > From: Kan Liang > > > > There could be different types of memory in the system. E.g normal > > System Memory, Persistent Memory. To understand how the workload > maps > > to those memories, it's important

RE: [PATCH V2] perf script: add script to profile and resolve physical mem type

Hi Arnaldo, Ping. Any comments for the script? Thanks, Kan > > > > From: Kan Liang > > > > There could be different types of memory in the system. E.g normal > > System Memory, Persistent Memory. To understand how the workload > maps > > to those memories, it's important to know the I/O

RE: [PATCH V2] perf script: add script to profile and resolve physical mem type

Hi all, Any comments for the patch? Thanks, Kan > > From: Kan Liang > > There could be different types of memory in the system. E.g normal > System Memory, Persistent Memory. To understand how the workload maps > to > those memories, it's important to know the I/O

RE: [PATCH V2] perf script: add script to profile and resolve physical mem type

Hi all, Any comments for the patch? Thanks, Kan > > From: Kan Liang > > There could be different types of memory in the system. E.g normal > System Memory, Persistent Memory. To understand how the workload maps > to > those memories, it's important to know the I/O statistics of them. > Perf

RE: [PATCH V4 1/8] perf/x86/intel/uncore: customized event_read for client IMC uncore

Hi Thomas, Any comments for this patch series? Thanks, Kan > > From: Kan Liang > > There are two free running counters for client IMC uncore. The custom > event_init() function hardcode their index to 'UNCORE_PMC_IDX_FIXED' and > 'UNCORE_PMC_IDX_FIXED + 1'. To support

RE: [PATCH V4 1/8] perf/x86/intel/uncore: customized event_read for client IMC uncore

Hi Thomas, Any comments for this patch series? Thanks, Kan > > From: Kan Liang > > There are two free running counters for client IMC uncore. The custom > event_init() function hardcode their index to 'UNCORE_PMC_IDX_FIXED' and > 'UNCORE_PMC_IDX_FIXED + 1'. To support the

RE: [PATCH 6/7] perf tools: Remove 'overwrite' concept from code level

> Since all 'overwrite' usage are cleaned and no one really use a readonly main > ringbuffer, remove 'overwrite' from function arguments and evlist. The > concept > of 'overwrite' and 'write_backward' are cleanner than before: > > 1. In code level, there's no 'overwrite' concept. Each evlist

RE: [PATCH 6/7] perf tools: Remove 'overwrite' concept from code level

> Since all 'overwrite' usage are cleaned and no one really use a readonly main > ringbuffer, remove 'overwrite' from function arguments and evlist. The > concept > of 'overwrite' and 'write_backward' are cleanner than before: > > 1. In code level, there's no 'overwrite' concept. Each evlist

RE: [PATCH 0/7] perf tools: Clarify overwrite and backward, bugfix

> Based on previous discussion, perf needs to support only two types > of ringbuffer: read-write + forward, readonly + backward. This patchset > completly removes the concept of 'overwrite' from code level, controls > mapping permission using write_backward instead. I think I suggested to remove

RE: [PATCH 0/7] perf tools: Clarify overwrite and backward, bugfix

> Based on previous discussion, perf needs to support only two types > of ringbuffer: read-write + forward, readonly + backward. This patchset > completly removes the concept of 'overwrite' from code level, controls > mapping permission using write_backward instead. I think I suggested to remove

RE: [PATCH V2] perf script: add script to profile and resolve physical mem type

Hi Stephane, Any comments for the script? Thanks, Kan > > From: Kan Liang > > There could be different types of memory in the system. E.g normal > System Memory, Persistent Memory. To understand how the workload maps > to > those memories, it's important to know the I/O

RE: [PATCH V2] perf script: add script to profile and resolve physical mem type

Hi Stephane, Any comments for the script? Thanks, Kan > > From: Kan Liang > > There could be different types of memory in the system. E.g normal > System Memory, Persistent Memory. To understand how the workload maps > to > those memories, it's important to know the I/O statistics of them. >

RE: [PATCH V3 1/5] perf/x86/intel/uncore: customized pmu event read for client IMC uncore

> On Thu, 2 Nov 2017, Liang, Kan wrote: > > > On Thu, 2 Nov 2017, Liang, Kan wrote: > > > > > On Thu, 2 Nov 2017, Thomas Gleixner wrote: > > > > > But then you have this in uncore_perf_event_update(): > > > > > &g

RE: [PATCH V3 1/5] perf/x86/intel/uncore: customized pmu event read for client IMC uncore

> On Thu, 2 Nov 2017, Liang, Kan wrote: > > > On Thu, 2 Nov 2017, Liang, Kan wrote: > > > > > On Thu, 2 Nov 2017, Thomas Gleixner wrote: > > > > > But then you have this in uncore_perf_event_update(): > > > > > &g

RE: [PATCH V3 1/5] perf/x86/intel/uncore: customized pmu event read for client IMC uncore

> On Thu, 2 Nov 2017, Liang, Kan wrote: > > > On Thu, 2 Nov 2017, Thomas Gleixner wrote: > > > But then you have this in uncore_perf_event_update(): > > > > > > - if (event->hw.idx >= UNCORE_PMC_IDX_FIXED) > > > + if (eve

RE: [PATCH V3 1/5] perf/x86/intel/uncore: customized pmu event read for client IMC uncore

> On Thu, 2 Nov 2017, Liang, Kan wrote: > > > On Thu, 2 Nov 2017, Thomas Gleixner wrote: > > > But then you have this in uncore_perf_event_update(): > > > > > > - if (event->hw.idx >= UNCORE_PMC_IDX_FIXED) > > > + if (eve

RE: [PATCH V3 1/5] perf/x86/intel/uncore: customized pmu event read for client IMC uncore

> On Thu, 2 Nov 2017, Thomas Gleixner wrote: > > On Thu, 2 Nov 2017, Liang, Kan wrote: > > > > On Thu, 2 Nov 2017, Thomas Gleixner wrote: > > > > > On Thu, 2 Nov 2017, Liang, Kan wrote: > > > > > > Patch 5/5 will clean up the client IMC unc

RE: [PATCH V3 1/5] perf/x86/intel/uncore: customized pmu event read for client IMC uncore

> On Thu, 2 Nov 2017, Thomas Gleixner wrote: > > On Thu, 2 Nov 2017, Liang, Kan wrote: > > > > On Thu, 2 Nov 2017, Thomas Gleixner wrote: > > > > > On Thu, 2 Nov 2017, Liang, Kan wrote: > > > > > > Patch 5/5 will clean up the client IMC unc

RE: [PATCH V3 1/5] perf/x86/intel/uncore: customized pmu event read for client IMC uncore

> On Thu, 2 Nov 2017, Thomas Gleixner wrote: > > On Thu, 2 Nov 2017, Liang, Kan wrote: > > > > On Tue, 24 Oct 2017, kan.li...@intel.com wrote: > > > > > - if (event->hw.idx >= UNCORE_PMC_IDX_FIXED) > > > > > + if (event->hw.idx

RE: [PATCH V3 1/5] perf/x86/intel/uncore: customized pmu event read for client IMC uncore

> On Thu, 2 Nov 2017, Thomas Gleixner wrote: > > On Thu, 2 Nov 2017, Liang, Kan wrote: > > > > On Tue, 24 Oct 2017, kan.li...@intel.com wrote: > > > > > - if (event->hw.idx >= UNCORE_PMC_IDX_FIXED) > > > > > + if (event->hw.idx

RE: [PATCH V3 1/5] perf/x86/intel/uncore: customized pmu event read for client IMC uncore

> On Tue, 24 Oct 2017, kan.li...@intel.com wrote: > > - if (event->hw.idx >= UNCORE_PMC_IDX_FIXED) > > + if (event->hw.idx == UNCORE_PMC_IDX_FIXED) > > shift = 64 - uncore_fixed_ctr_bits(box); > > else > > shift = 64 - uncore_perf_ctr_bits(box); diff --git > >

RE: [PATCH V3 1/5] perf/x86/intel/uncore: customized pmu event read for client IMC uncore

> On Tue, 24 Oct 2017, kan.li...@intel.com wrote: > > - if (event->hw.idx >= UNCORE_PMC_IDX_FIXED) > > + if (event->hw.idx == UNCORE_PMC_IDX_FIXED) > > shift = 64 - uncore_fixed_ctr_bits(box); > > else > > shift = 64 - uncore_perf_ctr_bits(box); diff --git > >

RE: [PATCH 1/2] perf mmap: Fix perf backward recording

Hi Namhyung, > On Wed, Nov 01, 2017 at 04:22:53PM +0000, Liang, Kan wrote: > > > On 2017/11/1 21:57, Liang, Kan wrote: > > > >> On 2017/11/1 20:00, Namhyung Kim wrote: > > > >>> On Wed, Nov 01, 2017 at 06:32:50PM +0800, Wangnan (F) wrote: > > >

RE: [PATCH 1/2] perf mmap: Fix perf backward recording

Hi Namhyung, > On Wed, Nov 01, 2017 at 04:22:53PM +0000, Liang, Kan wrote: > > > On 2017/11/1 21:57, Liang, Kan wrote: > > > >> On 2017/11/1 20:00, Namhyung Kim wrote: > > > >>> On Wed, Nov 01, 2017 at 06:32:50PM +0800, Wangnan (F) wrote: > > >

RE: [PATCH 1/2] perf mmap: Fix perf backward recording

> On 2017/11/1 21:57, Liang, Kan wrote: > >> On 2017/11/1 20:00, Namhyung Kim wrote: > >>> On Wed, Nov 01, 2017 at 06:32:50PM +0800, Wangnan (F) wrote: > >>>> On 2017/11/1 17:49, Namhyung Kim wrote: > >>>>> Hi, > >>>>> >

RE: [PATCH 1/2] perf mmap: Fix perf backward recording

> On 2017/11/1 21:57, Liang, Kan wrote: > >> On 2017/11/1 20:00, Namhyung Kim wrote: > >>> On Wed, Nov 01, 2017 at 06:32:50PM +0800, Wangnan (F) wrote: > >>>> On 2017/11/1 17:49, Namhyung Kim wrote: > >>>>> Hi, > >>>>> >

RE: [PATCH 2/2] perf record: Replace 'overwrite' by 'flightrecorder' for better naming

> On 2017/11/1 23:04, Liang, Kan wrote: > >> On 2017/11/1 22:22, Liang, Kan wrote: > >>>> On 2017/11/1 21:26, Liang, Kan wrote: > >>>>>> The meaning of perf record's "overwrite" option and many > "overwrite" > >>&

RE: [PATCH 2/2] perf record: Replace 'overwrite' by 'flightrecorder' for better naming

> On 2017/11/1 23:04, Liang, Kan wrote: > >> On 2017/11/1 22:22, Liang, Kan wrote: > >>>> On 2017/11/1 21:26, Liang, Kan wrote: > >>>>>> The meaning of perf record's "overwrite" option and many > "overwrite" > >>&

RE: [PATCH 2/2] perf record: Replace 'overwrite' by 'flightrecorder' for better naming

> On 2017/11/1 22:22, Liang, Kan wrote: > >> On 2017/11/1 21:26, Liang, Kan wrote: > >>>> The meaning of perf record's "overwrite" option and many "overwrite" > >>>> in source code are not clear. In perf's code, the 'over

RE: [PATCH 2/2] perf record: Replace 'overwrite' by 'flightrecorder' for better naming

> On 2017/11/1 22:22, Liang, Kan wrote: > >> On 2017/11/1 21:26, Liang, Kan wrote: > >>>> The meaning of perf record's "overwrite" option and many "overwrite" > >>>> in source code are not clear. In perf's code, the 'over

RE: [PATCH 2/2] perf record: Replace 'overwrite' by 'flightrecorder' for better naming

> On 2017/11/1 21:26, Liang, Kan wrote: > >> The meaning of perf record's "overwrite" option and many "overwrite" > >> in source code are not clear. In perf's code, the 'overwrite' has 2 > >> meanings: > >> 1. Make ringbuffer readon

RE: [PATCH 2/2] perf record: Replace 'overwrite' by 'flightrecorder' for better naming

> On 2017/11/1 21:26, Liang, Kan wrote: > >> The meaning of perf record's "overwrite" option and many "overwrite" > >> in source code are not clear. In perf's code, the 'overwrite' has 2 > >> meanings: > >> 1. Make ringbuffer readon

RE: [PATCH 1/2] perf mmap: Fix perf backward recording

> On 2017/11/1 20:00, Namhyung Kim wrote: > > On Wed, Nov 01, 2017 at 06:32:50PM +0800, Wangnan (F) wrote: > >> > >> On 2017/11/1 17:49, Namhyung Kim wrote: > >>> Hi, > >>> > >>> On Wed, Nov 01, 2017 at 05:53:26AM +, Wang Nan wrote: > perf record backward recording doesn't work as we

RE: [PATCH 1/2] perf mmap: Fix perf backward recording

> On 2017/11/1 20:00, Namhyung Kim wrote: > > On Wed, Nov 01, 2017 at 06:32:50PM +0800, Wangnan (F) wrote: > >> > >> On 2017/11/1 17:49, Namhyung Kim wrote: > >>> Hi, > >>> > >>> On Wed, Nov 01, 2017 at 05:53:26AM +, Wang Nan wrote: > perf record backward recording doesn't work as we

RE: [PATCH 2/2] perf record: Replace 'overwrite' by 'flightrecorder' for better naming

> The meaning of perf record's "overwrite" option and many "overwrite" in > source code are not clear. In perf's code, the 'overwrite' has 2 meanings: > 1. Make ringbuffer readonly (perf_evlist__mmap_ex's argument). > 2. Set evsel's "backward" attribute (in apply_config_terms). > > perf record

RE: [PATCH 2/2] perf record: Replace 'overwrite' by 'flightrecorder' for better naming

> The meaning of perf record's "overwrite" option and many "overwrite" in > source code are not clear. In perf's code, the 'overwrite' has 2 meanings: > 1. Make ringbuffer readonly (perf_evlist__mmap_ex's argument). > 2. Set evsel's "backward" attribute (in apply_config_terms). > > perf record

RE: [PATCH V3 0/6] event synthesization multithreading for perf record

> On Tue, Oct 24, 2017 at 11:22:00AM +0200, Ingo Molnar wrote: > > > > * Liang, Kan <kan.li...@intel.com> wrote: > > > > > For 'all', do you mean the whole process? > > > > Yeah. > > > > > I think that's the ultimate goal. E

RE: [PATCH V3 0/6] event synthesization multithreading for perf record

> On Tue, Oct 24, 2017 at 11:22:00AM +0200, Ingo Molnar wrote: > > > > * Liang, Kan wrote: > > > > > For 'all', do you mean the whole process? > > > > Yeah. > > > > > I think that's the ultimate goal. Eventually there will be per-CPU

RE: [PATCH] perf vendor events: Add Goldmont Plus V1 event file

> Em Thu, Oct 19, 2017 at 01:37:55PM -0700, Andi Kleen escreveu: > > On Thu, Oct 19, 2017 at 04:58:33PM -0300, Arnaldo Carvalho de Melo > wrote: > > > Em Wed, Oct 18, 2017 at 06:05:07AM -0700, kan.li...@intel.com > escreveu: > > > > From: Kan Liang > > > > > > > > Add a Intel

RE: [PATCH] perf vendor events: Add Goldmont Plus V1 event file

> Em Thu, Oct 19, 2017 at 01:37:55PM -0700, Andi Kleen escreveu: > > On Thu, Oct 19, 2017 at 04:58:33PM -0300, Arnaldo Carvalho de Melo > wrote: > > > Em Wed, Oct 18, 2017 at 06:05:07AM -0700, kan.li...@intel.com > escreveu: > > > > From: Kan Liang > > > > > > > > Add a Intel event file for perf.

RE: [PATCH V3 0/6] event synthesization multithreading for perf record

> Em Mon, Oct 23, 2017 at 01:43:39PM +0000, Liang, Kan escreveu: > > The plan is to do the multithreading step by step from the simplest case. > > Synthesizing stage is just a start. > > > Only for synthesizing stage, I think the patch series should already > > cove

RE: [PATCH V3 0/6] event synthesization multithreading for perf record

> Em Mon, Oct 23, 2017 at 01:43:39PM +0000, Liang, Kan escreveu: > > The plan is to do the multithreading step by step from the simplest case. > > Synthesizing stage is just a start. > > > Only for synthesizing stage, I think the patch series should already > > cove

RE: [PATCH V3 4/6] perf tools: add perf_data_file__open_tmp

> SNIP > > > > > ssize_t perf_data_file__write(struct perf_data_file *file, diff > > > > --git a/tools/perf/util/data.h b/tools/perf/util/data.h index > > > > ae510ce..892b3d5 100644 > > > > --- a/tools/perf/util/data.h > > > > +++ b/tools/perf/util/data.h > > > > @@ -10,6 +10,7 @@ enum

RE: [PATCH V3 4/6] perf tools: add perf_data_file__open_tmp

> SNIP > > > > > ssize_t perf_data_file__write(struct perf_data_file *file, diff > > > > --git a/tools/perf/util/data.h b/tools/perf/util/data.h index > > > > ae510ce..892b3d5 100644 > > > > --- a/tools/perf/util/data.h > > > > +++ b/tools/perf/util/data.h > > > > @@ -10,6 +10,7 @@ enum

RE: [PATCH V3 4/6] perf tools: add perf_data_file__open_tmp

> > From: Kan Liang > > > > And an interface for perf_data_file to open tmp file. > > Automatically generate the tmp file name if it's not assigned. The > > name cannot be const char. Introduce char *tmp_path for it. > > The tmp file will be deleted after close. > > > > It

RE: [PATCH V3 4/6] perf tools: add perf_data_file__open_tmp

> > From: Kan Liang > > > > And an interface for perf_data_file to open tmp file. > > Automatically generate the tmp file name if it's not assigned. The > > name cannot be const char. Introduce char *tmp_path for it. > > The tmp file will be deleted after close. > > > > It will be used as

RE: [PATCH V3 0/6] event synthesization multithreading for perf record

> * kan.li...@intel.com wrote: > > > The latency is the time cost of __machine__synthesize_threads or its > > multithreading replacement, record__multithread_synthesize. > > > > Original: original single thread synthesize > > With patch(not merge): multithread

RE: [PATCH V3 0/6] event synthesization multithreading for perf record

> * kan.li...@intel.com wrote: > > > The latency is the time cost of __machine__synthesize_threads or its > > multithreading replacement, record__multithread_synthesize. > > > > Original: original single thread synthesize > > With patch(not merge): multithread synthesize without

RE: [PATCH V2 0/5] event synthesization multithreading for perf record

> > * kan.li...@intel.com wrote: > > > From: Kan Liang > > > > The event synthesization multithreading is introduced in ("perf top > > optimization") https://lkml.org/lkml/2017/9/29/269 > > But it was not enabled for perf record. Because the process

RE: [PATCH V2 0/5] event synthesization multithreading for perf record

> > * kan.li...@intel.com wrote: > > > From: Kan Liang > > > > The event synthesization multithreading is introduced in ("perf top > > optimization") https://lkml.org/lkml/2017/9/29/269 > > But it was not enabled for perf record. Because the process function > > process_synthesized_event was

RE: [PATCH V2 1/4] perf/x86/intel/uncore: use same idx for clinet IMC uncore events

> > To specially handle it, event->hw.idx >= UNCORE_PMC_IDX_FIXED is used > to > > check fixed counters in the generic uncore_perf_event_update. > > It does not have problem in current code. > > I disagree. While it has no functional problem, it's a obscure hack which > means it is a code quality

RE: [PATCH V2 1/4] perf/x86/intel/uncore: use same idx for clinet IMC uncore events

> > To specially handle it, event->hw.idx >= UNCORE_PMC_IDX_FIXED is used > to > > check fixed counters in the generic uncore_perf_event_update. > > It does not have problem in current code. > > I disagree. While it has no functional problem, it's a obscure hack which > means it is a code quality

RE: [PATCH V2 4/5] perf record: synthesize event multithreading support

> On Wed, Oct 18, 2017 at 07:29:32AM -0700, kan.li...@intel.com wrote: > > SNIP > > > + rec->synthesized_file = calloc(nr_thread, sizeof(struct > perf_data_file)); > > + if (rec->synthesized_file == NULL) { > > + pr_debug("Could not do multithread synthesize." > > +

RE: [PATCH V2 4/5] perf record: synthesize event multithreading support

> On Wed, Oct 18, 2017 at 07:29:32AM -0700, kan.li...@intel.com wrote: > > SNIP > > > + rec->synthesized_file = calloc(nr_thread, sizeof(struct > perf_data_file)); > > + if (rec->synthesized_file == NULL) { > > + pr_debug("Could not do multithread synthesize." > > +

RE: [PATCH] perf script: add script to profile and resolve physical mem type

> > > > Right, it doesn’t need load latency. 0x81d0 should be a better choice. > > I will use 0x81d0 and 0x82d0 as default event for V2. > > That's model specific. You would need to check the model number if you do > that. > > Also with modern perf you can use the correct event names of course.

RE: [PATCH] perf script: add script to profile and resolve physical mem type

> > > > Right, it doesn’t need load latency. 0x81d0 should be a better choice. > > I will use 0x81d0 and 0x82d0 as default event for V2. > > That's model specific. You would need to check the model number if you do > that. > > Also with modern perf you can use the correct event names of course.

RE: [PATCH] perf script: add script to profile and resolve physical mem type

> On Tue, Oct 17, 2017 at 12:54 PM, Liang, Kan <kan.li...@intel.com> wrote: > >> On Mon, Oct 16, 2017 at 3:26 PM, <kan.li...@intel.com> wrote: > >> > From: Kan Liang <kan.li...@intel.com> > >> > > >> > There could be differ

RE: [PATCH] perf script: add script to profile and resolve physical mem type

> On Tue, Oct 17, 2017 at 12:54 PM, Liang, Kan wrote: > >> On Mon, Oct 16, 2017 at 3:26 PM, wrote: > >> > From: Kan Liang > >> > > >> > There could be different types of memory in the system. E.g normal > >> > System Memory,

RE: [PATCH] perf script: add script to profile and resolve physical mem type

> On Mon, Oct 16, 2017 at 3:26 PM, wrote: > > From: Kan Liang > > > > There could be different types of memory in the system. E.g normal > > System Memory, Persistent Memory. To understand how the workload > maps to > > those memories, it's important to

RE: [PATCH] perf script: add script to profile and resolve physical mem type

> On Mon, Oct 16, 2017 at 3:26 PM, wrote: > > From: Kan Liang > > > > There could be different types of memory in the system. E.g normal > > System Memory, Persistent Memory. To understand how the workload > maps to > > those memories, it's important to know the I/O statistics on different > >

RE: [PATCH 2/2] perf/x86/intel/uncore: support IIO freerunning counter for SKX

Ping. Any comments for this patch? Thanks, Kan > > From: Kan Liang > > As of Skylake Server, there are a number of free-running counters in > each IIO Box that collect counts for per box IO clocks and per Port > Input/Output x BW/Utilization. > > The event code of free

RE: [PATCH 2/2] perf/x86/intel/uncore: support IIO freerunning counter for SKX

Ping. Any comments for this patch? Thanks, Kan > > From: Kan Liang > > As of Skylake Server, there are a number of free-running counters in > each IIO Box that collect counts for per box IO clocks and per Port > Input/Output x BW/Utilization. > > The event code of free running event is

RE: [PATCH 3/4] perf record: event synthesization multithreading support

> Em Fri, Oct 13, 2017 at 07:09:26AM -0700, kan.li...@intel.com escreveu: > > From: Kan Liang > > > > The process function process_synthesized_event writes the process > > result to perf.data, which is not multithreading friendly. > > > > Realloc buffer for each thread to

RE: [PATCH 3/4] perf record: event synthesization multithreading support

> Em Fri, Oct 13, 2017 at 07:09:26AM -0700, kan.li...@intel.com escreveu: > > From: Kan Liang > > > > The process function process_synthesized_event writes the process > > result to perf.data, which is not multithreading friendly. > > > > Realloc buffer for each thread to temporarily keep the

RE: [PATCH 02/10] perf tool: fix: Don't discard prev in backward mode

> Em Fri, Oct 13, 2017 at 12:55:34PM +0000, Liang, Kan escreveu: > > > Em Tue, Oct 10, 2017 at 10:20:15AM -0700, kan.li...@intel.com escreveu: > > > > From: Kan Liang <kan.li...@intel.com> > > > > > > > > Perf record can switch output. T

RE: [PATCH 02/10] perf tool: fix: Don't discard prev in backward mode

> Em Fri, Oct 13, 2017 at 12:55:34PM +0000, Liang, Kan escreveu: > > > Em Tue, Oct 10, 2017 at 10:20:15AM -0700, kan.li...@intel.com escreveu: > > > > From: Kan Liang > > > > > > > > Perf record can switch output. The new output should only

RE: [PATCH 02/10] perf tool: fix: Don't discard prev in backward mode

> Em Tue, Oct 10, 2017 at 10:20:15AM -0700, kan.li...@intel.com escreveu: > > From: Kan Liang > > > > Perf record can switch output. The new output should only store the > > data after switching. However, in overwrite backward mode, the new > > output still have the data from

RE: [PATCH 02/10] perf tool: fix: Don't discard prev in backward mode

> Em Tue, Oct 10, 2017 at 10:20:15AM -0700, kan.li...@intel.com escreveu: > > From: Kan Liang > > > > Perf record can switch output. The new output should only store the > > data after switching. However, in overwrite backward mode, the new > > output still have the data from old output. > > > >

RE: [PATCH] perf tool: Don't discard prev in backward mode

d processed data. > > Avoid calling backward_rb_find_range() when md->prev is still available. > > Signed-off-by: Wang Nan <wangn...@huawei.com> > Cc: Liang Kan <kan.li...@intel.com> > --- The patch looks good to me. Tested-by: Kan Liang <kan.li...@intel.com> > tools

RE: [PATCH] perf tool: Don't discard prev in backward mode

d processed data. > > Avoid calling backward_rb_find_range() when md->prev is still available. > > Signed-off-by: Wang Nan > Cc: Liang Kan > --- The patch looks good to me. Tested-by: Kan Liang > tools/perf/util/mmap.c | 33 +++-- > 1 file changed, 15 i

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