On 11/6/2018 10:00 AM, Stephane Eranian wrote:
/*
* mmap 1 page at the location of the unmap page (should reuse virtual space)
* This creates a continuous region built from two mmaps and
potentially two different sources
* especially with jitted runtimes
*/
The two mmaps are both anon. As my
On Mon, Nov 5, 2018 at 7:43 AM Liang, Kan wrote:
>
>
>
> On 11/5/2018 5:59 AM, Stephane Eranian wrote:
> > Hi Kan,
> >
> > I built a small test case for you to demonstrate the issue for code and
> > data.
> > Compile the test program and then do:
> > For text:
> > $ perf record ./mmap
> > $ perf
On 11/5/2018 5:59 AM, Stephane Eranian wrote:
Hi Kan,
I built a small test case for you to demonstrate the issue for code and data.
Compile the test program and then do:
For text:
$ perf record ./mmap
$ perf report -D | fgrep MMAP2
The test program mmaps 2 pages, unmaps the second, and rema
Hi Kan,
I built a small test case for you to demonstrate the issue for code and data.
Compile the test program and then do:
For text:
$ perf record ./mmap
$ perf report -D | fgrep MMAP2
The test program mmaps 2 pages, unmaps the second, and remap 1 page
over the freed space.
If you look at the M
On 10/24/2018 3:30 PM, Stephane Eranian wrote:
The need for this new record type extends beyond physical address conversions
and PEBS. A long while ago, someone reported issues with symbolization related
to perf lacking munmap tracking. It had to do with vma merging. I think the
sequence of mm
On Thu, Oct 25, 2018 at 10:00:07AM -0400, Liang, Kan wrote:
> Is this patch you mentioned?
> https://lkml.org/lkml/2017/1/27/452
Yes.
On 10/24/2018 8:29 PM, Peter Zijlstra wrote:
On Wed, Oct 24, 2018 at 08:11:15AM -0700, kan.li...@linux.intel.com wrote:
+void perf_event_munmap(void)
+{
+ struct perf_cpu_context *cpuctx;
+ unsigned long flags;
+ struct pmu *pmu;
+
+ local_irq_save(flags);
It is impo
On Wed, Oct 24, 2018 at 5:34 PM Peter Zijlstra wrote:
>
> On Wed, Oct 24, 2018 at 05:25:59PM -0700, Stephane Eranian wrote:
> > On Wed, Oct 24, 2018 at 5:23 PM Peter Zijlstra wrote:
>
> > > That is actually a different problem. And you're right, we never did fix
> > > that.
> > >
> > it is a diff
On Wed, Oct 24, 2018 at 08:11:15AM -0700, kan.li...@linux.intel.com wrote:
> +void perf_event_munmap(void)
> +{
> + struct perf_cpu_context *cpuctx;
> + unsigned long flags;
> + struct pmu *pmu;
> +
> + local_irq_save(flags);
It is impossible to get here with IRQs already disabled.
On Wed, Oct 24, 2018 at 05:25:59PM -0700, Stephane Eranian wrote:
> On Wed, Oct 24, 2018 at 5:23 PM Peter Zijlstra wrote:
> > That is actually a different problem. And you're right, we never did fix
> > that.
> >
> it is a different problem but the solution is the same: PERF_RECORD_UNMAP!
But he
On Wed, Oct 24, 2018 at 11:28:54AM -0700, Andi Kleen wrote:
> > > void perf_event_mmap(struct vm_area_struct *vma)
> > > {
> > > struct perf_mmap_event mmap_event;
> > >
> > > if (!atomic_read(&nr_mmap_events))
> > > return;
> > >
> > > }
> > >
> >
> > Thanks.
On Wed, Oct 24, 2018 at 5:23 PM Peter Zijlstra wrote:
>
> On Wed, Oct 24, 2018 at 12:30:52PM -0700, Stephane Eranian wrote:
> > Hi,
> >
> > On Wed, Oct 24, 2018 at 8:12 AM wrote:
> > >
> > > From: Kan Liang
> > >
> > > To calculate the physical address, perf needs to walk the pages tables.
> > >
On Wed, Oct 24, 2018 at 12:30:52PM -0700, Stephane Eranian wrote:
> Hi,
>
> On Wed, Oct 24, 2018 at 8:12 AM wrote:
> >
> > From: Kan Liang
> >
> > To calculate the physical address, perf needs to walk the pages tables.
> > The related mapping may has already been removed from pages table in
> >
Hi,
On Wed, Oct 24, 2018 at 8:12 AM wrote:
>
> From: Kan Liang
>
> To calculate the physical address, perf needs to walk the pages tables.
> The related mapping may has already been removed from pages table in
> some cases (e.g. large PEBS). The virtual address recorded in the first
> PEBS recor
Em Wed, Oct 24, 2018 at 02:12:54PM -0400, Liang, Kan escreveu:
>
>
> On 10/24/2018 12:32 PM, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Oct 24, 2018 at 09:23:34AM -0700, Andi Kleen escreveu:
> > > > +void perf_event_munmap(void)
> > > > +{
> > > > + struct perf_cpu_context *cpuctx;
> > > >
> > void perf_event_mmap(struct vm_area_struct *vma)
> > {
> > struct perf_mmap_event mmap_event;
> >
> > if (!atomic_read(&nr_mmap_events))
> > return;
> >
> > }
> >
>
> Thanks. I'll add the nr_mmap_events check in V2.
No, that's the wrong check here. The PE
On 10/24/2018 12:32 PM, Arnaldo Carvalho de Melo wrote:
Em Wed, Oct 24, 2018 at 09:23:34AM -0700, Andi Kleen escreveu:
+void perf_event_munmap(void)
+{
+ struct perf_cpu_context *cpuctx;
+ unsigned long flags;
+ struct pmu *pmu;
+
+ local_irq_save(flags);
+ list_
Em Wed, Oct 24, 2018 at 09:23:34AM -0700, Andi Kleen escreveu:
> > +void perf_event_munmap(void)
> > +{
> > + struct perf_cpu_context *cpuctx;
> > + unsigned long flags;
> > + struct pmu *pmu;
> > +
> > + local_irq_save(flags);
> > + list_for_each_entry(cpuctx, this_cpu_ptr(&sched_cb_list
> +void perf_event_munmap(void)
> +{
> + struct perf_cpu_context *cpuctx;
> + unsigned long flags;
> + struct pmu *pmu;
> +
> + local_irq_save(flags);
> + list_for_each_entry(cpuctx, this_cpu_ptr(&sched_cb_list),
> sched_cb_entry) {
Would be good have a fast path here that che
From: Kan Liang
To calculate the physical address, perf needs to walk the pages tables.
The related mapping may has already been removed from pages table in
some cases (e.g. large PEBS). The virtual address recorded in the first
PEBS records may already be unmapped before draining PEBS buffers.
20 matches
Mail list logo
