perf: add ability to sample physical data addresses

Make sure intel_pmu_pebs_disable() and intel_pmu_pebs_enable() are symmetrical w.r.t. PEBS-LL and precise store.

Signed-off-by Stephane Eranian <[email protected]>

---
 arch/x86/kernel/cpu/perf_event_intel_ds.c | 6 ++++++
 1 file changed, 6 insertions(+)

arch/x86/kernel/cpu/perf_event_intel_ds.c +6 -0

index ed3e553..3065c57 100644
@@ -653,6 +653,12 @@ void intel_pmu_pebs_disable(struct perf_event *event)
 	struct hw_perf_event *hwc = &event->hw;
 
 	cpuc->pebs_enabled &= ~(1ULL << hwc->idx);
+
+	if (event->hw.constraint->flags & PERF_X86_EVENT_PEBS_LDLAT)
+		cpuc->pebs_enabled &= ~(1ULL << (hwc->idx + 32));
+	else if (event->hw.constraint->flags & PERF_X86_EVENT_PEBS_ST)
+		cpuc->pebs_enabled &= ~(1ULL << 63);
+
 	if (cpuc->enabled)
 		wrmsrl(MSR_IA32_PEBS_ENABLE, cpuc->pebs_enabled);
 

Signature · 1 line

1.8.1.2

Quoted 4 lines · Stephane Eranian

Make sure intel_pmu_pebs_disable() and intel_pmu_pebs_enable() are symmetrical w.r.t. PEBS-LL and precise store.

Signed-off-by Stephane Eranian <[email protected]>

This seems unrelated to the actual patch series and should still go in.

Quoted 25 lines

---
 arch/x86/kernel/cpu/perf_event_intel_ds.c | 6 ++++++
 1 file changed, 6 insertions(+)

arch/x86/kernel/cpu/perf_event_intel_ds.c +6 -1

index ed3e553..3065c57 100644
@@ -653,6 +653,12 @@ void intel_pmu_pebs_disable(struct perf_event *event)
      struct hw_perf_event *hwc = &event->hw;
 
      cpuc->pebs_enabled &= ~(1ULL << hwc->idx);
+
+     if (event->hw.constraint->flags & PERF_X86_EVENT_PEBS_LDLAT)
+             cpuc->pebs_enabled &= ~(1ULL << (hwc->idx + 32));
+     else if (event->hw.constraint->flags & PERF_X86_EVENT_PEBS_ST)
+             cpuc->pebs_enabled &= ~(1ULL << 63);
+
      if (cpuc->enabled)
              wrmsrl(MSR_IA32_PEBS_ENABLE, cpuc->pebs_enabled);
 
--

1.8.1.2

Now that we use the contraints directly from the event, we do not need the event->flags field so drop it.

Signed-off-by Stephane Eranian <[email protected]>

Quoted 4 lines · Stephane Eranian

Now that we use the contraints directly from the event, we do not need the event->flags field so drop it.

Signed-off-by Stephane Eranian <[email protected]>

Same for this one I suppose; its not really related to the series at hand.

Quoted 8 lines · Peter Zijlstra

Quoted 4 lines · Stephane Eranian

Now that we use the contraints directly from the event, we do not need the event->flags field so drop it.

Signed-off-by Stephane Eranian <[email protected]>

Same for this one I suppose; its not really related to the series at hand.

Correct. I can submit separately if needed.

Quoted 11 lines · Stephane Eranian

Quoted 8 lines · Peter Zijlstra

Quoted 4 lines · Stephane Eranian

Now that we use the contraints directly from the event, we do not need the event->flags field so drop it.

Signed-off-by Stephane Eranian <[email protected]>

Same for this one I suppose; its not really related to the series at hand.

Correct. I can submit separately if needed.

I applied the first patch; this one failed to apply.. Remind me again if I fail to remember looking at the rejects once I've collected all other patches I planned to ship to mingo today.

Peter,

I don't this see patch in tip.git yet.

Quoted 3 lines · Stephane Eranian

Peter,

I don't this see patch in tip.git yet.

Didn't apply and I didn't get around to beating it into shape; could you resend against tip/master. Ingo just pushed out all the other bits.

Ok, the chunks that do not apply can be ignored for perf_event_intel.c.

Quoted 1 line · Stephane Eranian

Ok, the chunks that do not apply can be ignored for perf_event_intel.c.

Just to verify; I did a force apply ignoring the 2 hunks in perf_event_intel.c. The result is the below patch; which gives:

# nice make O=defconfig-build/ -j16 -s
/usr/src/linux-2.6/arch/x86/kernel/cpu/perf_event.c: In function ‘x86_schedule_events’:
/usr/src/linux-2.6/arch/x86/kernel/cpu/perf_event.c:780:9: error: ‘struct hw_perf_event’ has no member named ‘flags’
/usr/src/linux-2.6/arch/x86/kernel/cpu/perf_event.c:794:14: error: ‘struct hw_perf_event’ has no member named ‘flags’
/usr/src/linux-2.6/arch/x86/kernel/cpu/perf_event.c: In function ‘x86_pmu_del’:
/usr/src/linux-2.6/arch/x86/kernel/cpu/perf_event.c:1180:11: error: ‘struct hw_perf_event’ has no member named ‘flags’
make[4]: *** [arch/x86/kernel/cpu/perf_event.o] Error 1

Please resend one that builds.

---
Subject: perf,x86: Drop event->flags and use hw.constraint->flags
From: Stephane Eranian <[email protected]>
Date: Fri, 21 Jun 2013 16:20:42 +0200

Now that we use the constraints directly from the event, we do not need the event->flags field so drop it.

Signed-off-by Stephane Eranian <[email protected]>

Signed-off-by Peter Zijlstra <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

---
 arch/x86/kernel/cpu/perf_event_intel_ds.c |   19 ++++++++++---------
 include/linux/perf_event.h                |    1 -
 2 files changed, 10 insertions(+), 10 deletions(-)

arch/x86/kernel/cpu/perf_event_intel_ds.c +10 -9

@@ -623,7 +623,6 @@ struct event_constraint *intel_pebs_cons
        if (x86_pmu.pebs_constraints) {
                for_each_event_constraint(c, x86_pmu.pebs_constraints) {
                        if ((event->hw.config & c->cmask) == c->code) {
-                               event->hw.flags |= c->flags;
                                return c;
                        }
                }

@@ -636,14 +635,15 @@ void intel_pmu_pebs_enable(struct perf_e
 {
        struct cpu_hw_events *cpuc = &__get_cpu_var(cpu_hw_events);
        struct hw_perf_event *hwc = &event->hw;
+       int flags = event->hw.constraint->flags;
 
        hwc->config &= ~ARCH_PERFMON_EVENTSEL_INT;
 
        cpuc->pebs_enabled |= 1ULL << hwc->idx;
 
-       if (event->hw.flags & PERF_X86_EVENT_PEBS_LDLAT)
+       if (flags & PERF_X86_EVENT_PEBS_LDLAT)
                cpuc->pebs_enabled |= 1ULL << (hwc->idx + 32);
-       else if (event->hw.flags & PERF_X86_EVENT_PEBS_ST)
+       else if (flags & PERF_X86_EVENT_PEBS_ST)
                cpuc->pebs_enabled |= 1ULL << 63;
 }
 

@@ -651,12 +651,13 @@ void intel_pmu_pebs_disable(struct perf_
 {
        struct cpu_hw_events *cpuc = &__get_cpu_var(cpu_hw_events);
        struct hw_perf_event *hwc = &event->hw;
+       int flags = event->hw.constraint->flags;
 
        cpuc->pebs_enabled &= ~(1ULL << hwc->idx);
 
-       if (event->hw.constraint->flags & PERF_X86_EVENT_PEBS_LDLAT)
+       if (flags & PERF_X86_EVENT_PEBS_LDLAT)
                cpuc->pebs_enabled &= ~(1ULL << (hwc->idx + 32));
-       else if (event->hw.constraint->flags & PERF_X86_EVENT_PEBS_ST)
+       else if (flags & PERF_X86_EVENT_PEBS_ST)
                cpuc->pebs_enabled &= ~(1ULL << 63);
 
        if (cpuc->enabled)

@@ -772,14 +773,14 @@ static void __intel_pmu_pebs_event(struc
        struct perf_sample_data data;
        struct pt_regs regs;
        u64 sample_type;
+       int flags = event->hw.constraint->flags;
        int fll, fst;
 
        if (!intel_pmu_save_and_restart(event))
                return;
 
-       fll = event->hw.flags & PERF_X86_EVENT_PEBS_LDLAT;
-       fst = event->hw.flags & (PERF_X86_EVENT_PEBS_ST |
-                                PERF_X86_EVENT_PEBS_ST_HSW);
+       fll = flags & PERF_X86_EVENT_PEBS_LDLAT;
+       fst = flags & (PERF_X86_EVENT_PEBS_ST | PERF_X86_EVENT_PEBS_ST_HSW);
 
        perf_sample_data_init(&data, 0, event->hw.last_period);
 

@@ -802,7 +803,7 @@ static void __intel_pmu_pebs_event(struc
                if (sample_type & PERF_SAMPLE_DATA_SRC) {
                        if (fll)
                                data.data_src.val = load_latency_data(pebs->dse);
-                       else if (event->hw.flags & PERF_X86_EVENT_PEBS_ST_HSW)
+                       else if (flags & PERF_X86_EVENT_PEBS_ST_HSW)
                                data.data_src.val =
                                        precise_store_data_hsw(pebs->dse);
                        else

include/linux/perf_event.h +0 -1

@@ -134,7 +134,6 @@ struct hw_perf_event {
                        int             event_base_rdpmc;
                        int             idx;
                        int             last_cpu;
-                       int             flags;
 
                        struct hw_perf_event_extra extra_reg;
                        struct hw_perf_event_extra branch_reg;

Peter,

Let's drop this patch.

It does not work anymore with the offcore-response scheduling fix. The constraint->flags are shared, so cannot use the flags there to store X86_COMMITTED. So we have to keep a copy in the event->hw.flags.

Sorry about the confusion.

This patch series extends perf_events with the ability to sample physical data addresses. This is useful with the memory access sampling mode added just recently. In particular, it helps disambiguate data addresses between two processes, such as in the case of a shared memory segment mapped at different addresses in different processes.

Quoted 6 lines · Stephane Eranian

This patch series extends perf_events with the ability to sample physical data addresses. This is useful with the memory access sampling mode added just recently. In particular, it helps disambiguate data addresses between two processes, such as in the case of a shared memory segment mapped at different addresses in different processes.

hi,
what is this patchset based on?
I cannot apply this on tip nor on acme's tree.

thanks,
jirka

Hi,

It applies and compiles for me on tip.git:

4ce9207 Merge branch 'x86/platform'

This patch series extends perf_events with the ability to sample physical data addresses. This is useful with the memory access sampling mode added just recently. In particular, it helps disambiguate data addresses between two processes, such as in the case of a shared memory segment mapped at different addresses in different processes.

The patch adds the PERF_SAMPLE_PHYS_ADDR sample_type. A 64-bit address is added to the sample record for the corresponding event.

On Intel X86, it is used with the PEBS Load Latency support. On other architectures, zero is returned.

The patch series also demonstrates the use of this new feature by extending perf report, mem, record with a --phys-addr option. When enable, it will capture physical data address and display it. This is implemented as a new sort_order (symbol_paddr).

Quoted 11 lines · Stephane Eranian

This patch series extends perf_events with the ability to sample physical data addresses. This is useful with the memory access sampling mode added just recently. In particular, it helps disambiguate data addresses between two processes, such as in the case of a shared memory segment mapped at different addresses in different processes.

The patch adds the PERF_SAMPLE_PHYS_ADDR sample_type. A 64-bit address is added to the sample record for the corresponding event.

Quoted 9 lines

On Intel X86, it is used with the PEBS Load Latency support. On other architectures, zero is returned.

The patch series also demonstrates the use of this new feature by extending perf report, mem, record with a --phys-addr option. When enable, it will capture physical data address and display it. This is implemented as a new sort_order (symbol_paddr).

So I'm a bit puzzled by this thing...

What exact problem are we trying to solve here? Only the shared memory mapped at different addresses between processes thing mentioned earlier?

The big problem I see with all this is that typically memory is subject to being moved about at random; be it either from paging, compaction, NUMA policies or explicit page migration.

Such would completely shatter physical page relations.

If the shared memory thing is really the issue, doesn't perf already have the process memory layout (/proc/$PID/maps and aux stream mmap updates) with which it can compute map relative offsets and compare thusly?

One guarantee we have is that the physical does correspond to the virtual address at the time of the interrupt.

But yeah, if physical pages are swapped during the run, then things become a lot more complicated. I am not trying to address this.

Can page move for shared memory segments?

Quoted 6 lines

Such would completely shatter physical page relations.

If the shared memory thing is really the issue, doesn't perf already have the process memory layout (/proc/$PID/maps and aux stream mmap updates) with which it can compute map relative offsets and compare thusly?

Not sure I understand this.
suppose the same shared memory segment is mapped at two different addresses by shmat(). First, I don't know if those show up in /proc/maps.

Second, what offset are you talking about here?

Quoted 2 lines · Stephane Eranian

One guarantee we have is that the physical does correspond to the virtual address at the time of the interrupt.

That might not be much of a guarantee depending on the circumstances.

Quoted 4 lines

But yeah, if physical pages are swapped during the run, then things become a lot more complicated. I am not trying to address this.

Can page move for shared memory segments?

Yep..

Quoted 7 lines

Quoted 6 lines

Such would completely shatter physical page relations.

If the shared memory thing is really the issue, doesn't perf already have the process memory layout (/proc/$PID/maps and aux stream mmap updates) with which it can compute map relative offsets and compare thusly?

Quoted 3 lines

Not sure I understand this.
suppose the same shared memory segment is mapped at two different addresses by shmat(). First, I don't know if those show up in /proc/maps.

They should; IIRC maps is a full vma list.. /me prods about in fs/proc/task_mmu.c.. yes it prints all vmas.

A syscall (ioctl?) to dump all current vmas into the mmap update stream (to form a starting point) might be handy - that would remove the fragility and overhead of parsing /proc/ details.

Quoted 3 lines · Ingo Molnar

A syscall (ioctl?) to dump all current vmas into the mmap update stream (to form a starting point) might be handy - that would remove the fragility and overhead of parsing /proc/ details.

Its more difficult than that though :/ Suppose not all mmap events fit in the output buffer and you're not able to read from the buffer because you're stuck in the ioctl().

This means we need to either force userspace to use threads to reliably use the feature; or complicate the ioctl() to allow vma ranges -- which introduces an inherent race window etc..

Neither option are really pretty and we already have the maps parse code -- also its not _that_ hard to parse either.

After more investigation with the author of the false sharing detection tool, I think
that if the mapping changes, it is okay. The tool can detect this and drop the analysis
at that address. So as long as we can flag the mapping change, we are okay. Hopefully,
it does not occur frequently. If so, then I think there are bigger issues to fix on the system
than false sharing.

Quoted 9 lines · Stephane Eranian

After more investigation with the author of the false sharing detection tool, I think
that if the mapping changes, it is okay. The tool can detect this and drop the analysis
at that address. So as long as we can flag the mapping change, we are okay. Hopefully,
it does not occur frequently. If so, then I think there are bigger issues to fix on the system
than false sharing.

But if you index everything using dev:inode:offset it doesn't matter if the mapping changes; you're invariant to map placement.

And the thing is; we already compute most of that anyway in order to find the code in DSOs, except there we use filename instead of dev:inode. However if there were means to open files using dev:inode that might actually be more reliable than using the filename.

So, I tried on an example using shmat(). I map the same shared segment twice in the same process. Then I fork(): I see this in /proc/PID/maps:

7f80fce28000-7f80fce29000 rw-s 00000000 00:04 1376262
/SYSV00000000 (deleted)
7f80fce29000-7f80fce2a000 rw-s 00000000 00:04 1343491
/SYSV00000000 (deleted)
7f80fce2a000-7f80fce2b000 rw-s 00000000 00:04 1343491
/SYSV00000000 (deleted)

The segment at 1343491 is the one mapped twice. So that number (shmid) can be used to identify identical mappings. It appears the same way in both processes. The other 1376262 mapping is just to verify that each segment gets a different number.

So it looks possible to use this approach across process to identify identical physical mappings. However, this is not very practical.

The first reason is that perf_event does not capture shmat() mappings in MMAP records.

The second is is that if you rely on /proc/PID/maps, you will have to have the tool
constantly poll that file for new shared mappings. This is not how perf works today,
not even in system-wide mode. /proc/PID/maps is swept only once when perf record -a is started.

Ingo is proposing a ioctl() to flush the mappings. But then, when is a good time to do this
from the tool?

So my approach with PERF_SAMPLE_PHYS_ADDR looks easier on the tools which if I recall is the philosophy behind perf_events.

Quoted 10 lines · Stephane Eranian

So, I tried on an example using shmat(). I map the same shared segment twice in the same process. Then I fork(): I see this in /proc/PID/maps:

7f80fce28000-7f80fce29000 rw-s 00000000 00:04 1376262
/SYSV00000000 (deleted)
7f80fce29000-7f80fce2a000 rw-s 00000000 00:04 1343491
/SYSV00000000 (deleted)
7f80fce2a000-7f80fce2b000 rw-s 00000000 00:04 1343491
/SYSV00000000 (deleted)

Quoted 4 lines

The segment at 1343491 is the one mapped twice. So that number (shmid) can be used to identify identical mappings. It appears the same way in both processes. The other 1376262 mapping is just to verify that each segment gets a different number.

Right, that's the inode number; I think you also need to add the blockdev id (00:04) in this case as inode numbers are per device, not global.

Quoted 5 lines

So it looks possible to use this approach across process to identify identical physical mappings. However, this is not very practical.

The first reason is that perf_event does not capture shmat() mappings in MMAP records.

oops, that would be something we'd definitely need to fix.

ipc/shm.c:SYSCALL_DEFINE3(shmat)
do_shmat()

    do_mmap_pgoff()
      mmap_region()
        perf_event_mmap()

So why isn't it logging them? If its a non-exec map we need attr::mmap_data but I suppose you have that enabled?

Quoted 6 lines

The second is is that if you rely on /proc/PID/maps, you will have to have the tool
constantly poll that file for new shared mappings. This is not how perf works today,
not even in system-wide mode. /proc/PID/maps is swept only once when perf record -a is started.

Ahh. We don't put the useful bits in the mmap event; we'll need to fix that too then ;-)

Doing so is going to be a bit of a bother since we use the tail of PERF_RECORD_MMAP for filenames and thus aren't particularly extensible.

This would mean doing something like PERF_RECORD_MMAP2 and some means for userspace to requrest the new events instead of the old one.

Didn't you already have patches to change the event layout? Can this piggy back on that?

Quoted 3 lines

Ingo is proposing a ioctl() to flush the mappings. But then, when is a good time to do this
from the tool?

Yeah, that's not going to help with this; that's only to get rid of the initial /proc/$pid/maps reading. Not to keep up with changes.

Quoted 2 lines

So my approach with PERF_SAMPLE_PHYS_ADDR looks easier on the tools which if I recall is the philosophy behind perf_events.

Physical addresses are always going to cause problems, don't ever use them.

Quoted 10 lines · Stephane Eranian

So, I tried on an example using shmat(). I map the same shared segment twice in the same process. Then I fork(): I see this in /proc/PID/maps:

7f80fce28000-7f80fce29000 rw-s 00000000 00:04 1376262
/SYSV00000000 (deleted)
7f80fce29000-7f80fce2a000 rw-s 00000000 00:04 1343491
/SYSV00000000 (deleted)
7f80fce2a000-7f80fce2b000 rw-s 00000000 00:04 1343491
/SYSV00000000 (deleted)

Quoted 4 lines

The segment at 1343491 is the one mapped twice. So that number (shmid) can be used to identify identical mappings. It appears the same way in both processes. The other 1376262 mapping is just to verify that each segment gets a different number.

Right, that's the inode number; I think you also need to add the blockdev id (00:04) in this case as inode numbers are per device, not global.

Quoted 5 lines

So it looks possible to use this approach across process to identify identical physical mappings. However, this is not very practical.

The first reason is that perf_event does not capture shmat() mappings in MMAP records.

oops, that would be something we'd definitely need to fix.

ipc/shm.c:SYSCALL_DEFINE3(shmat)
do_shmat()

    do_mmap_pgoff()
      mmap_region()
        perf_event_mmap()

So why isn't it logging them? If its a non-exec map we need attr::mmap_data but I suppose you have that enabled?

Quoted 6 lines

The second is is that if you rely on /proc/PID/maps, you will have to have the tool
constantly poll that file for new shared mappings. This is not how perf works today,
not even in system-wide mode. /proc/PID/maps is swept only once when perf record -a is started.

Ahh. We don't put the useful bits in the mmap event; we'll need to fix that too then ;-)

Doing so is going to be a bit of a bother since we use the tail of PERF_RECORD_MMAP for filenames and thus aren't particularly extensible.

This would mean doing something like PERF_RECORD_MMAP2 and some means for userspace to requrest the new events instead of the old one.

Quoted 6 lines

Ahh. We don't put the useful bits in the mmap event; we'll need to fix that too then ;-)

Doing so is going to be a bit of a bother since we use the tail of PERF_RECORD_MMAP for filenames and thus aren't particularly extensible.

Quoted 3 lines

This would mean doing something like PERF_RECORD_MMAP2 and some means for userspace to requrest the new events instead of the old one.

Tracking mmaps even for shmat() won't cover the paging cases. When you page a page back in, it most likely gets a different physical page. How would we track that
case too using the same approach?

Quoted 9 lines · Stephane Eranian

Quoted 9 lines

Ahh. We don't put the useful bits in the mmap event; we'll need to fix that too then ;-)

Doing so is going to be a bit of a bother since we use the tail of PERF_RECORD_MMAP for filenames and thus aren't particularly extensible.

This would mean doing something like PERF_RECORD_MMAP2 and some means for userspace to requrest the new events instead of the old one.

Quoted 4 lines

Tracking mmaps even for shmat() won't cover the paging cases. When you page a page back in, it most likely gets a different physical page. How would we track that
case too using the same approach?

It doesn't matter. Even if a page ends up being a different physical page, it will always be the same sb:inode:pgoffset. You should be able to always uniquely identify a (shared) page by that triplet.

So if we create a net MMAP record that includes the device (substitute for the superblock) and inode information we should be good.

Quoted 10 lines · Peter Zijlstra

Quoted 9 lines · Stephane Eranian

Quoted 9 lines

Ahh. We don't put the useful bits in the mmap event; we'll need to fix that too then ;-)

Doing so is going to be a bit of a bother since we use the tail of PERF_RECORD_MMAP for filenames and thus aren't particularly extensible.

This would mean doing something like PERF_RECORD_MMAP2 and some means for userspace to requrest the new events instead of the old one.

Quoted 9 lines

Quoted 4 lines

Tracking mmaps even for shmat() won't cover the paging cases. When you page a page back in, it most likely gets a different physical page. How would we track that
case too using the same approach?

It doesn't matter. Even if a page ends up being a different physical page, it will always be the same sb:inode:pgoffset. You should be able to always uniquely identify a (shared) page by that triplet.

Ok, so you're saying that triplet uniquely identifies a virtual page regardless of
the physical page it is mapped onto. If the physical page changes because of paging, we keep the same triplet and therefore we can still detect the false sharing.

Quoted 2 lines

So if we create a net MMAP record that includes the device (substitute for the superblock) and inode information we should be good.

I will try that. I am not familiar with mm, so where do we find the device? Inside
the vma?

Quoted 20 lines · Stephane Eranian

Quoted 19 lines · Peter Zijlstra

Quoted 6 lines · Stephane Eranian

Quoted 6 lines

Ahh. We don't put the useful bits in the mmap event; we'll need to fix that too then ;-)

Doing so is going to be a bit of a bother since we use the tail of PERF_RECORD_MMAP for filenames and thus aren't particularly extensible.

Quoted 7 lines

Quoted 3 lines

This would mean doing something like PERF_RECORD_MMAP2 and some means for userspace to requrest the new events instead of the old one.

Tracking mmaps even for shmat() won't cover the paging cases. When you page a page back in, it most likely gets a different physical page. How would we track that
case too using the same approach?

It doesn't matter. Even if a page ends up being a different physical page, it will always be the same sb:inode:pgoffset. You should be able to always uniquely identify a (shared) page by that triplet.

Quoted 5 lines

Ok, so you're saying that triplet uniquely identifies a virtual page regardless of
the physical page it is mapped onto. If the physical page changes because of paging, we keep the same triplet and therefore we can still detect the false sharing.

Exactly.

Quoted 6 lines

Quoted 2 lines

So if we create a net MMAP record that includes the device (substitute for the superblock) and inode information we should be good.

I will try that. I am not familiar with mm, so where do we find the device? Inside
the vma?

Take a peek at fs/proc/task_mmu.c:show_map_vma(), its the code used to print /proc/$PID/maps and displays all stuff we want.

Quoted 21 lines · Peter Zijlstra

Quoted 20 lines · Stephane Eranian

Quoted 19 lines · Peter Zijlstra

Quoted 6 lines · Stephane Eranian

Quoted 6 lines

Ahh. We don't put the useful bits in the mmap event; we'll need to fix that too then ;-)

Doing so is going to be a bit of a bother since we use the tail of PERF_RECORD_MMAP for filenames and thus aren't particularly extensible.

Quoted 7 lines

Quoted 3 lines

This would mean doing something like PERF_RECORD_MMAP2 and some means for userspace to requrest the new events instead of the old one.

Tracking mmaps even for shmat() won't cover the paging cases. When you page a page back in, it most likely gets a different physical page. How would we track that
case too using the same approach?

It doesn't matter. Even if a page ends up being a different physical page, it will always be the same sb:inode:pgoffset. You should be able to always uniquely identify a (shared) page by that triplet.

Quoted 8 lines

Quoted 5 lines

Ok, so you're saying that triplet uniquely identifies a virtual page regardless of
the physical page it is mapped onto. If the physical page changes because of paging, we keep the same triplet and therefore we can still detect the false sharing.

Exactly.

I see this for my program:

7f0a59cbe000-7f0a59cc1000 rw-p 00000000 00:00 0 7f0a59cd3000-7f0a59cd4000 rw-p 00000000 00:00 0 7f0a59cd4000-7f0a59cd5000 rw-s 00000000 00:04 458753
/SYSV00000000 (deleted)
7f0a59cd5000-7f0a59cd6000 rw-s 00000000 00:04 425984
/SYSV00000000 (deleted)
7f0a59cd6000-7f0a59cd7000 rw-s 00000000 00:04 425984
/SYSV00000000 (deleted)

The first 2 lines are heap. There is nothing useful coming out of maj:min ino. However for shared segment we can use the ino number. Shared memory segment appear as file in the vma therefore, the kernel does use the ino, maj, min number.
And in my program I map the same segment twice, and we see the last two mappings are identical.

But in the case of regular paging, there is no useful info there. But thenI suspect for a private
heap page we only care about multi-threaded and there the physical page is irrelevant.
So it seems all we care about is to cover the shared segment case and we can get the
info from the vma and creates a MMAP2 record for it.

Do we agree?

Quoted 9 lines

Quoted 6 lines

Quoted 2 lines

So if we create a net MMAP record that includes the device (substitute for the superblock) and inode information we should be good.

I will try that. I am not familiar with mm, so where do we find the device? Inside
the vma?

Take a peek at fs/proc/task_mmu.c:show_map_vma(), its the code used to print /proc/$PID/maps and displays all stuff we want.

That is what I see in that function:

       if (file) {
                struct inode *inode = file_inode(vma->vm_file);
                dev = inode->i_sb->s_dev;
                ino = inode->i_ino;
                pgoff = ((loff_t)vma->vm_pgoff) << PAGE_SHIFT;
        }

It works for anything associated with a file.

One thing that bothers me with the MMAP2 approach is that it forces integration into perf. Now, you will need to analyze the MMAP2 records. With my sample_type approach, you simply needed a cmdline option on perf record, and then you could dump the sample using perf report -D and feed

them into a post-processing script. But now, the analysis needs to be integrated into perf or the tool needs to parse the full perf.data file.

Quoted 6 lines · Stephane Eranian

One thing that bothers me with the MMAP2 approach is that it forces integration into perf. Now, you will need to analyze the MMAP2 records. With my sample_type approach, you simply needed a cmdline option on perf record, and then you could dump the sample using perf report -D and feed

what do you want that is not coming out via perf-script?

Quoted 4 lines

them into a post-processing script. But now, the analysis needs to be integrated into perf or the tool needs to parse the full perf.data file.

you mean parsed during perf-record?

Quoted 9 lines · David Ahern

Quoted 6 lines · Stephane Eranian

One thing that bothers me with the MMAP2 approach is that it forces integration into perf. Now, you will need to analyze the MMAP2 records. With my sample_type approach, you simply needed a cmdline option on perf record, and then you could dump the sample using perf report -D and feed

Quoted 2 lines

what do you want that is not coming out via perf-script?

mmap records. Are they passed to scripts?

Peter,

One thing that bothers me with the MMAP2 approach is that it forces integration into perf.

Now, you will need to analyze
the MMAP2 records. With my sample_type approach, you simply needed a cmdline option on perf record, and then you could dump the sample using perf report -D and feed them into a post-processing script. But now, the analysis needs to be integrated into perf or the tool needs to parse the full perf.data file.

Quoted 4 lines · Stephane Eranian

Peter,

One thing that bothers me with the MMAP2 approach is that it forces integration into perf.

This is a good (TM) thing, yes? ;-)

Quoted 7 lines

Now, you will need to analyze
the MMAP2 records. With my sample_type approach, you simply needed a cmdline option on perf record, and then you could dump the sample using perf report -D and feed them into a post-processing script. But now, the analysis needs to be integrated into perf or the tool needs to parse the full perf.data file.

So the disadvantage of the sample_type approach is that it generates more data and bloats the fast path.

If its useful it shouldn't live in a script anyway ;-) Also if the script muck can't deal with the side-band information its a worse broken piece of crap than I thought it was.

Quoted 6 lines · Peter Zijlstra

Quoted 4 lines · Stephane Eranian

Peter,

One thing that bothers me with the MMAP2 approach is that it forces integration into perf.

Quoted 2 lines

This is a good (TM) thing, yes? ;-)

Well, that's one way to look at it. But I'd like the API to be able to support more than one tool easily. If the barrier for any advanced analysis is too high from the raw kernel API then we will only have one tool. I don't think that sane.

Quoted 7 lines

Quoted 6 lines

Such would completely shatter physical page relations.

If the shared memory thing is really the issue, doesn't perf already have the process memory layout (/proc/$PID/maps and aux stream mmap updates) with which it can compute map relative offsets and compare thusly?

Quoted 3 lines

Not sure I understand this.
suppose the same shared memory segment is mapped at two different addresses by shmat(). First, I don't know if those show up in /proc/maps.

They should; IIRC maps is a full vma list.. /me prods about in fs/proc/task_mmu.c.. yes it prints all vmas.