perf: add two new features

The capabilities bits must not be "union'ed" together. Put them in a separate struct.

Signed-off-by Adrian Hunter <[email protected]>

---
 include/uapi/linux/perf_event.h | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

include/uapi/linux/perf_event.h +0 -0

index 0b1df41..19f6ee5 100644
@@ -375,9 +375,11 @@ struct perf_event_mmap_page {
 	__u64	time_running;		/* time event on cpu */
 	union {

Ick, it did that!? and here I thought there was a difference between:

int foo:1,

      bar:1;

and

int foo:1;
int bar:1;

That made all the difference in this particular case. I guess I should go read the language spec more carefully next time.

Commit-ID:  860f085b74e9f0075de8140ed3a1e5b5e3e39aa8
Gitweb:     http://git.kernel.org/tip/860f085b74e9f0075de8140ed3a1e5b5e3e39aa8
Author:     Adrian Hunter <[email protected]>
AuthorDate: Fri, 28 Jun 2013 16:22:17 +0300
Committer:  Ingo Molnar <[email protected]>
CommitDate: Tue, 23 Jul 2013 12:17:10 +0200

perf: Fix broken union in 'struct perf_event_mmap_page'

The capabilities bits must not be "union'ed" together. Put them in a separate struct.

Signed-off-by Adrian Hunter <[email protected]>

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

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

Signed-off-by Ingo Molnar <[email protected]>

---
 include/uapi/linux/perf_event.h | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

include/uapi/linux/perf_event.h +5 -4

index 00d8274..0041aed 100644
@@ -375,9 +375,11 @@ struct perf_event_mmap_page {
 	__u64	time_running;		/* time event on cpu */
 	union {
 		__u64	capabilities;
-		__u64	cap_usr_time  : 1,
-			cap_usr_rdpmc : 1,
-			cap_____res   : 62;
+		struct {
+			__u64	cap_usr_time		: 1,
+				cap_usr_rdpmc		: 1,
+				cap_____res		: 62;
+		};
 	};
 
 	/*
--

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

This patch somehow breaks the perf-ABI.

If I take a program that reads "mmap->cap_usr_rdpmc" and compile it against the new header with this change (say from 3.12-rc1) and then run it on an old kernel (say 3.11) then I get "0" for cap_usr_rdpmc.

If I take the same program and recompile against the old (without this patch) header and run it on 3.11, I get the expected "1" value.

Quoted 10 lines · Vince Weaver

This patch somehow breaks the perf-ABI.

If I take a program that reads "mmap->cap_usr_rdpmc" and compile it against the new header with this change (say from 3.12-rc1) and then run it on an old kernel (say 3.11) then I get "0" for cap_usr_rdpmc.

If I take the same program and recompile against the old (without this patch) header and run it on 3.11, I get the expected "1" value.

To follow up, the original case:

        union {
                __u64   capabilities;
                __u64   cap_usr_time  : 1,
                        cap_usr_rdpmc : 1,
                        cap_____res   : 62;
        };

        Then mmap->usr_rdpmc=1; gets assembled as

        400420:       80 0d 11 05 20 00 02    orb    $0x2,0x200511(%rip)        

The new version

       union {
                __u64   capabilities;
                struct {
                        __u64   cap_usr_time            : 1,
                                cap_usr_rdpmc           : 1,
                                cap_usr_time_zero       : 1,
                                cap_____res             : 61;
                };
        };

        mmap->usr_rdpmc=1; gets assembled as


       400427:       80 0d 02 05 20 00 01    orb    $0x1,0x200502(%rip)        

note the difference in the or value.

Quoted 14 lines

 include/uapi/linux/perf_event.h | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

include/uapi/linux/perf_event.h +0 -3

index 00d8274..0041aed 100644
@@ -375,9 +375,11 @@ struct perf_event_mmap_page {
 	__u64	time_running;		/* time event on cpu */
 	union {
 		__u64	capabilities;
-		__u64	cap_usr_time  : 1,
-			cap_usr_rdpmc : 1,
-			cap_____res   : 62;

include/uapi/linux/perf_event.h struct perf_event_mmap_page { · line 383

Quoted 6 lines

include/uapi/linux/perf_event.h +5 -0

+		struct {
+			__u64	cap_usr_time		: 1,
+				cap_usr_rdpmc		: 1,
+				cap_____res		: 62;
+		};
 	};

This patch somehow breaks the perf-ABI.

If I take a program that reads "mmap->cap_usr_rdpmc" and compile it against the new header with this change (say from 3.12-rc1) and then run it on an old kernel (say 3.11) then I get "0" for cap_usr_rdpmc.

If I take the same program and recompile against the old (without this patch) header and run it on 3.11, I get the expected "1" value.

So something about this changed the bit pattern in an incompatible fashion.

Quoted 1 line

This patch somehow breaks the perf-ABI.

Difficult call that..

Can you point to any code that is fixed by the commit?

Quoted 1 line · Vince Weaver

Can you point to any code that is fixed by the commit?

I have some, but I don't think a lot of people use it.

Would you be ok with something like the below? It should preserve functionality for code that only cares about cap_usr_rdpmc (PAPI).

Stephane, does libpfm use any of these?

include/uapi/linux/perf_event.h +2 -2

@@ -380,8 +380,8 @@ struct perf_event_mmap_page {
        union {
                __u64   capabilities;
                struct {
-                       __u64   cap_usr_time            : 1,
-                               cap_usr_rdpmc           : 1,
+                       __u64   cap_usr_rdpmc           : 1,
+                               cap_usr_time            : 1,
                                cap_usr_time_zero       : 1,
                                cap_____res             : 61;
                };

Quoted 5 lines · Peter Zijlstra

Quoted 1 line · Vince Weaver

Can you point to any code that is fixed by the commit?

I have some, but I don't think a lot of people use it.

Quoted 5 lines

Would you be ok with something like the below? It should preserve functionality for code that only cares about cap_usr_rdpmc (PAPI).

Stephane, does libpfm use any of these?

Yes, there is an example using this. Need to verify it is not broken currently (self_count.c).

Quoted 11 lines · Stephane Eranian

Quoted 10 lines · Peter Zijlstra

Quoted 1 line · Vince Weaver

Can you point to any code that is fixed by the commit?

I have some, but I don't think a lot of people use it.

Would you be ok with something like the below? It should preserve functionality for code that only cares about cap_usr_rdpmc (PAPI).

Stephane, does libpfm use any of these?

Quoted 2 lines

Yes, there is an example using this. Need to verify it is not broken currently (self_count.c).

So if that only uses cap_usr_rdpmc, you have the same issue as Vince and the proposed solutions would work for you too.

If you also use cap_usr_time we've a bit of a problem.

Quoted 15 lines · Peter Zijlstra

Quoted 13 lines · Stephane Eranian

Quoted 10 lines · Peter Zijlstra

Quoted 1 line · Vince Weaver

Can you point to any code that is fixed by the commit?

I have some, but I don't think a lot of people use it.

Would you be ok with something like the below? It should preserve functionality for code that only cares about cap_usr_rdpmc (PAPI).

Stephane, does libpfm use any of these?

Yes, there is an example using this. Need to verify it is not broken currently (self_count.c).

Quoted 4 lines

So if that only uses cap_usr_rdpmc, you have the same issue as Vince and the proposed solutions would work for you too.

If you also use cap_usr_time we've a bit of a problem.

I need to look at this program again, was written a long time ago. It does not use cap_usr_rdpmc nor cap_use_time for sure.

Quoted 1 line · Vince Weaver

Can you point to any code that is fixed by the commit?

I have some, but I don't think a lot of people use it.

Would you be ok with something like the below? It should preserve functionality for code that only cares about cap_usr_rdpmc (PAPI).

Stephane, does libpfm use any of these?

It would be nice if there was some way to detect this change; I liked the idea of a "cap_usr_fixed" bit.

Quoted 2 lines · Vince Weaver

It would be nice if there was some way to detect this change; I liked the idea of a "cap_usr_fixed" bit.

How about we start using the version field for this? Arguably we should have incremented that value every time we changed the thing but we might as well start now.

include/uapi/linux/perf_event.h +3 -1

@@ -442,12 +445,14 @@ struct perf_event_mmap_page {
 	 *               ((rem * time_mult) >> time_shift);
 	 */
 	__u64	time_zero;
+	__u32	size;			/* Header size up to this point */
+	__u32	__reserved0;		/* 4 byte hole */
 
 		/*
 		 * Hole for extension of the self monitor capabilities
 		 */
 
-	__u64	__reserved[119];	/* align to 1k */
+	__u64	__reserved[118];	/* align to 1k */
 
 	/*
 	 * Control data for the mmap() data buffer.

kernel/events/core.c +5 -0

index dd236b6..27d339f 100644
@@ -3660,6 +3660,26 @@ static void calc_timer_values(struct perf_event *event,
 	*running = ctx_time - event->tstamp_running;
 }
 
+static void perf_event_init_userpage(struct perf_event *event)
+{
+	struct perf_event_mmap_page *userpg;
+	struct ring_buffer *rb;
+

kernel/events/core.c +4 -0

+
+unlock:
+	rcu_read_unlock();
+}

Quoted 29 lines · Ingo Molnar

(quoted diff) +3 -1

@@ -442,12 +445,14 @@ struct perf_event_mmap_page {
 	 *               ((rem * time_mult) >> time_shift);
 	 */
 	__u64	time_zero;
+	__u32	size;			/* Header size up to this point */
+	__u32	__reserved0;		/* 4 byte hole */
 
 		/*
 		 * Hole for extension of the self monitor capabilities
 		 */
 
-	__u64	__reserved[119];	/* align to 1k */
+	__u64	__reserved[118];	/* align to 1k */
 
 	/*
 	 * Control data for the mmap() data buffer.

kernel/events/core.c +5 -0

index dd236b6..27d339f 100644
@@ -3660,6 +3660,26 @@ static void calc_timer_values(struct perf_event *event,
 	*running = ctx_time - event->tstamp_running;
 }
 
+static void perf_event_init_userpage(struct perf_event *event)
+{
+	struct perf_event_mmap_page *userpg;
+	struct ring_buffer *rb;
+

kernel/events/core.c static void calc_timer_values(struct perf_event *event, · line 3677

Quoted 10 lines

kernel/events/core.c +10 -0

+	rcu_read_lock();
+	rb = rcu_dereference(event->rb);
+	if (!rb)
+		goto unlock;
+
+	userpg = rb->user_page;
+
+	/* Allow new userspace to detect that bit 0 is deprecated */
+	userpg->cap_bit0_is_deprecated = 1;
+	userpg->size = offsetof(struct perf_event_mmap_page, size);

This is fragile and I'm 100% sure we'll forget to update it.

	userpg->size = offsetof(struct perf_event_mmap_page, __reserved);

Will auto update and mostly do the right thing.

Also, how will userspace know there's a valid size field way out there?

Shouldn't we bump the version field to indicate so? :-) After all, running on old userspace this field will be 0.

arch/x86/kernel/cpu/perf_event.c +5 -5

index 8355c84..3ab624c 100644
@@ -1883,9 +1883,9 @@ static struct pmu pmu = {
 
 void arch_perf_update_userpage(struct perf_event_mmap_page *userpg, u64 now)
 {
-	userpg->cap_usr_time = 0;
-	userpg->cap_usr_time_zero = 0;
-	userpg->cap_usr_rdpmc = x86_pmu.attr_rdpmc;
+	userpg->cap_usr_time_used = 0;
+	userpg->cap_usr_time_zero_used = 0;
+	userpg->cap_usr_rdpmc_available = x86_pmu.attr_rdpmc;
 	userpg->pmc_width = x86_pmu.cntval_bits;
 
 	if (!boot_cpu_has(X86_FEATURE_CONSTANT_TSC))

@@ -1894,13 +1894,13 @@ void arch_perf_update_userpage(struct perf_event_mmap_page *userpg, u64 now)
 	if (!boot_cpu_has(X86_FEATURE_NONSTOP_TSC))
 		return;
 
-	userpg->cap_usr_time = 1;
+	userpg->cap_usr_time_used = 1;
 	userpg->time_mult = this_cpu_read(cyc2ns);
 	userpg->time_shift = CYC2NS_SCALE_FACTOR;
 	userpg->time_offset = this_cpu_read(cyc2ns_offset) - now;
 
 	if (sched_clock_stable && !check_tsc_disabled()) {
-		userpg->cap_usr_time_zero = 1;
+		userpg->cap_usr_time_zero_used = 1;
 		userpg->time_zero = this_cpu_read(cyc2ns_offset);
 	}
 }

include/uapi/linux/perf_event.h +0 -3

index 40a1fb8..e3514d1 100644
@@ -380,10 +380,13 @@ struct perf_event_mmap_page {
 	union {
 		__u64	capabilities;
 		struct {
-			__u64	cap_usr_time		: 1,
-				cap_usr_rdpmc		: 1,
-				cap_usr_time_zero	: 1,

On Thu, Sep 19, 2013 at 12:28:18PM +0200, Ingo Molnar wrote:

You really don't like version fields do you ;-)

Would it make sense to do something like s/cap_usr/cap_user/ and drop the _available, _used postfixes? It results in different names but avoids these terribly long ones.

Quoted 3 lines · Peter Zijlstra

On Thu, Sep 19, 2013 at 12:28:18PM +0200, Ingo Molnar wrote:

You really don't like version fields do you ;-)

Indeed they are a horrible concept.

Quoted 3 lines

Would it make sense to do something like s/cap_usr/cap_user/ and drop the _available, _used postfixes? It results in different names but avoids these terribly long ones.

Absolutely! Find updated patch below.

Thanks,

Ingo

arch/x86/kernel/cpu/perf_event.c +5 -5

index 8355c84..a9c606b 100644
@@ -1883,9 +1883,9 @@ static struct pmu pmu = {
 
 void arch_perf_update_userpage(struct perf_event_mmap_page *userpg, u64 now)
 {
-	userpg->cap_usr_time = 0;
-	userpg->cap_usr_time_zero = 0;
-	userpg->cap_usr_rdpmc = x86_pmu.attr_rdpmc;
+	userpg->cap_user_time = 0;
+	userpg->cap_user_time_zero = 0;
+	userpg->cap_user_rdpmc = x86_pmu.attr_rdpmc;
 	userpg->pmc_width = x86_pmu.cntval_bits;
 
 	if (!boot_cpu_has(X86_FEATURE_CONSTANT_TSC))

@@ -1894,13 +1894,13 @@ void arch_perf_update_userpage(struct perf_event_mmap_page *userpg, u64 now)
 	if (!boot_cpu_has(X86_FEATURE_NONSTOP_TSC))
 		return;
 
-	userpg->cap_usr_time = 1;
+	userpg->cap_user_time = 1;
 	userpg->time_mult = this_cpu_read(cyc2ns);
 	userpg->time_shift = CYC2NS_SCALE_FACTOR;
 	userpg->time_offset = this_cpu_read(cyc2ns_offset) - now;
 
 	if (sched_clock_stable && !check_tsc_disabled()) {
-		userpg->cap_usr_time_zero = 1;
+		userpg->cap_user_time_zero = 1;
 		userpg->time_zero = this_cpu_read(cyc2ns_offset);
 	}
 }

include/uapi/linux/perf_event.h +9 -5

index 40a1fb8..dd4c903 100644
@@ -380,10 +380,13 @@ struct perf_event_mmap_page {
 	union {
 		__u64	capabilities;
 		struct {
-			__u64	cap_usr_time		: 1,
-				cap_usr_rdpmc		: 1,
-				cap_usr_time_zero	: 1,
-				cap_____res		: 61;
+			__u64	cap_bit0		: 1, /* Always 0, deprecated, see commit 860f085b74e9 */
+				cap_bit0_is_deprecated	: 1, /* Always 1, signals that bit 0 is zero */
+
+				cap_user_rdpmc		: 1, /* The RDPMC instruction can be used to read counts */
+				cap_user_time		: 1, /* The time_* fields are used */
+				cap_user_time_zero	: 1, /* The time_zero field is used */
+				cap_____res		: 59;
 		};
 	};
 

@@ -442,12 +445,13 @@ struct perf_event_mmap_page {
 	 *               ((rem * time_mult) >> time_shift);
 	 */
 	__u64	time_zero;
+	__u32	size;			/* Header size up to __reserved[] fields. */
 
 		/*
 		 * Hole for extension of the self monitor capabilities
 		 */
 
-	__u64	__reserved[119];	/* align to 1k */
+	__u8	__reserved[118*8+4];	/* align to 1k. */
 
 	/*
 	 * Control data for the mmap() data buffer.

kernel/events/core.c +20 -0

index dd236b6..cb4238e 100644
@@ -3660,6 +3660,26 @@ static void calc_timer_values(struct perf_event *event,
 	*running = ctx_time - event->tstamp_running;
 }
 
+static void perf_event_init_userpage(struct perf_event *event)
+{
+	struct perf_event_mmap_page *userpg;
+	struct ring_buffer *rb;
+
+	rcu_read_lock();
+	rb = rcu_dereference(event->rb);
+	if (!rb)
+		goto unlock;
+
+	userpg = rb->user_page;
+
+	/* Allow new userspace to detect that bit 0 is deprecated */
+	userpg->cap_bit0_is_deprecated = 1;
+	userpg->size = offsetof(struct perf_event_mmap_page, __reserved);
+
+unlock:
+	rcu_read_unlock();
+}
+
 void __weak arch_perf_update_userpage(struct perf_event_mmap_page *userpg, u64 now)
 {
 }

Quoted 7 lines

(quoted diff) +2 -4

 		struct {
-			__u64	cap_usr_time		: 1,
-				cap_usr_rdpmc		: 1,
-				cap_usr_time_zero	: 1,
-				cap_____res		: 61;
+			__u64	cap_bit0		: 1, /* Always 0, deprecated, see commit 860f085b74e9 */
+				cap_bit0_is_deprecated	: 1, /* Always 1, signals that bit 0 is zero */

Review

Quoted 6 lines

(quoted diff) +5 -0

+
+				cap_user_rdpmc		: 1, /* The RDPMC instruction can be used to read counts */
+				cap_user_time		: 1, /* The time_* fields are used */
+				cap_user_time_zero	: 1, /* The time_zero field is used */
+				cap_____res		: 59;
 		};

Please consider adding:

To solve all that make this change explicit, detectable and self-contained, by iterating the ABI the following way:

- Always clear bit 0, and rename it to usrpage->cap_bit0, to at least not confuse old user-space binaries. RDPMC will be marked as unavailable to old binaries but that's within the ABI, this is a capability bit.

- Rename bit 1 to ->cap_bit0_is_deprecated and always set it to 1, so new libraries can reliably detect that bit 0 is deprecated and perma-zero without having to check the kernel version.

- Use bits 2, 3, 4 for the newly defined, correct functionality:

cap_user_rdpmc : 1, /* The RDPMC instruction can be used to read counts */
cap_user_time : 1, /* The time_* fields are used */
cap_user_time_zero : 1, /* The time_zero field is used */

- Rename all the bitfield names in perf_event.h to be different from the old names, to make sure it's not possible to mis-compile it accidentally with old assumptions.

Quoted 11 lines · Ingo Molnar

To solve all that make this change explicit, detectable and self-contained, by iterating the ABI the following way:

- Always clear bit 0, and rename it to usrpage->cap_bit0, to at least not confuse old user-space binaries. RDPMC will be marked as unavailable to old binaries but that's within the ABI, this is a capability bit.

- Rename bit 1 to ->cap_bit0_is_deprecated and always set it to 1, so new libraries can reliably detect that bit 0 is deprecated and perma-zero without having to check the kernel version.

Quoted 6 lines

- Use bits 2, 3, 4 for the newly defined, correct functionality:

cap_user_rdpmc : 1, /* The RDPMC instruction can be used to read counts */
cap_user_time : 1, /* The time_* fields are used */
cap_user_time_zero : 1, /* The time_zero field is used */

So let me think through the possible combinations:

OLD-KERNEL OLD-HEADER
+ cap_usr_rdpmc and cap_usr_time map to the same bit
+ In general for kernels from 3.4 to 3.11 the bit will be set for all x86

NEW-KERNEL OLD-HEADER
+ cap_usr_rdpmc (cap_bit0) and cap_usr_time (cap_bit0) both are 0
+ code detecting cap_usr_rdpmc will probably fall back to non-rdpmc even through rdpmc code is probably there and functioning

OLD-KERNEL NEW-HEADER
+ cap_user_rdpmc and cap_user_time both set to 0
+ cap_bit0_is_deprecated can be read; if it is 0 you can read cap_bit0, and if it is 1, assume rdpmc is available with the same likelyhood you could with the old header

NEW-KERNEL NEW-HEADER
+ Use cap_user_rdpmc and cap_user_time and everything is OK

Quoted 3 lines

- Rename all the bitfield names in perf_event.h to be different from the old names, to make sure it's not possible to mis-compile it accidentally with old assumptions.

Well this breaks that API, though I guess there are no guarantees there.

I guess that's intentional since it will force users to fix their code, but a pain if you aren't expecting it and suddenly your project doesn't compile anymore after a kernel-headers update. Most of my code carries around its own perf_event.h so I guess I'll be unaffected.

In any case this seems to be about as reasonable a solution to this problem as we can get.

This patch somehow breaks the perf-ABI.

If I take a program that reads "mmap->cap_usr_rdpmc" and compile it against the new header with this change (say from 3.12-rc1) and then run it on an old kernel (say 3.11) then I get "0" for cap_usr_rdpmc.

If I take the same program and recompile against the old (without this patch) header and run it on 3.11, I get the expected "1" value.

So something about this changed the bit pattern in an incompatible fashion.

Vince

Quoted 40 lines · tip-bot for Adrian Hunter

Commit-ID:  860f085b74e9f0075de8140ed3a1e5b5e3e39aa8
Gitweb:     http://git.kernel.org/tip/860f085b74e9f0075de8140ed3a1e5b5e3e39aa8
Author:     Adrian Hunter <[email protected]>
AuthorDate: Fri, 28 Jun 2013 16:22:17 +0300
Committer:  Ingo Molnar <[email protected]>
CommitDate: Tue, 23 Jul 2013 12:17:10 +0200

perf: Fix broken union in 'struct perf_event_mmap_page'

The capabilities bits must not be "union'ed" together. Put them in a separate struct.

Signed-off-by Adrian Hunter <[email protected]>

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

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

Signed-off-by Ingo Molnar <[email protected]>

---
 include/uapi/linux/perf_event.h | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

include/uapi/linux/perf_event.h +5 -4

index 00d8274..0041aed 100644
@@ -375,9 +375,11 @@ struct perf_event_mmap_page {
 	__u64	time_running;		/* time event on cpu */
 	union {
 		__u64	capabilities;
-		__u64	cap_usr_time  : 1,
-			cap_usr_rdpmc : 1,
-			cap_____res   : 62;
+		struct {
+			__u64	cap_usr_time		: 1,
+				cap_usr_rdpmc		: 1,
+				cap_____res		: 62;
+		};
 	};
 
 	/*
--

Quoted 5 lines

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

k

Quoted 11 lines · Vince Weaver

This patch somehow breaks the perf-ABI.

If I take a program that reads "mmap->cap_usr_rdpmc" and compile it against the new header with this change (say from 3.12-rc1) and then run it on an old kernel (say 3.11) then I get "0" for cap_usr_rdpmc.

If I take the same program and recompile against the old (without this patch) header and run it on 3.11, I get the expected "1" value.

Quoted 2 lines

So something about this changed the bit pattern in an incompatible fashion.

cap_usr_time and cap_usr_rdpmc were occupying the same bit position i.e. bit 0

That means that cap_usr_time and cap_usr_rdpmc were both unreliable.

From what it originally sounded like this was just some shuffling of

Possible improvements are one or both of:
1. Add cap_usr_fixed to identify kernels that have the capabilities bits fixed
2. Swap the positions of cap_usr_time and cap_usr_rdpmc so that cap_usr_rdpmc remains in bit 0

Hi

Please consider these two new perf features:
x86: add ability to calculate TSC from perf sample timestamps
perf: add 'keep tracking' flag to PERF_EVENT_IOC_DISABLE

Quoted 5 lines · Adrian Hunter

Hi

Please consider these two new perf features:
x86: add ability to calculate TSC from perf sample timestamps
perf: add 'keep tracking' flag to PERF_EVENT_IOC_DISABLE

Please explain to us why you'd like to do this..

Quoted 7 lines · Peter Zijlstra

Quoted 5 lines · Adrian Hunter

Hi

Please consider these two new perf features:
x86: add ability to calculate TSC from perf sample timestamps
perf: add 'keep tracking' flag to PERF_EVENT_IOC_DISABLE

Quoted 1 line

Please explain to us why you'd like to do this..

I will see what information I can dig up. The short answer is that I need to disable and re-enable a perf event but still be able to map IPs to their DSOs and symbols - which means not losing mmap events.

Quoted 8 lines · Adrian Hunter

Quoted 7 lines · Peter Zijlstra

Quoted 5 lines · Adrian Hunter

Hi

Please consider these two new perf features:
x86: add ability to calculate TSC from perf sample timestamps
perf: add 'keep tracking' flag to PERF_EVENT_IOC_DISABLE

Quoted 5 lines

Quoted 1 line

Please explain to us why you'd like to do this..

I will see what information I can dig up. The short answer is that I need to disable and re-enable a perf event but still be able to map IPs to their DSOs and symbols - which means not losing mmap events.

Any other comments?

Quoted 15 lines · Adrian Hunter

Quoted 13 lines · Adrian Hunter

Quoted 8 lines · Peter Zijlstra

Quoted 5 lines · Adrian Hunter

Hi

Please consider these two new perf features:
x86: add ability to calculate TSC from perf sample timestamps
perf: add 'keep tracking' flag to PERF_EVENT_IOC_DISABLE

Please explain to us why you'd like to do this..

I will see what information I can dig up. The short answer is that I need to disable and re-enable a perf event but still be able to map IPs to their DSOs and symbols - which means not losing mmap events.

Quoted 1 line

Any other comments?

Ah, thanks for the reminder.. well, I've applied patches 1-3 as those seem useful on their own. I'm not entirely convinced about the 'keep tracking' thing though.

It seems to me you could get the same by opening a second event into the same buffer and keeping that enabled.