2015-04-28 15:51:49

by Shreyas B. Prabhu

[permalink] [raw]
Subject: [PATCH 1/3] tracing/mm: Don't trace kmem_cache_free on offline cpus

Since tracepoints use RCU for protection, they must not be called on
offline cpus. trace_kmem_cache_free can be called on an offline cpu in
this scenario caught by LOCKDEP:

===============================
[ INFO: suspicious RCU usage. ]
4.1.0-rc1+ #9 Not tainted
-------------------------------
include/trace/events/kmem.h:148 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

RCU used illegally from offline CPU!
rcu_scheduler_active = 1, debug_locks = 1
no locks held by swapper/1/0.

stack backtrace:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.1.0-rc1+ #9
Call Trace:
[c000001fed2f78f0] [c0000000009dee8c] .dump_stack+0x98/0xd4 (unreliable)
[c000001fed2f7970] [c000000000128d88] .lockdep_rcu_suspicious+0x108/0x170
[c000001fed2f7a00] [c00000000026f924] .kmem_cache_free+0x344/0x4b0
[c000001fed2f7ab0] [c0000000000bd1cc] .__mmdrop+0x4c/0x160
[c000001fed2f7b40] [c0000000001068e0] .idle_task_exit+0xf0/0x100
[c000001fed2f7bc0] [c000000000066948] .pnv_smp_cpu_kill_self+0x58/0x2c0
[c000001fed2f7ca0] [c00000000003ce34] .cpu_die+0x34/0x50
[c000001fed2f7d10] [c0000000000176d0] .arch_cpu_idle_dead+0x20/0x40
[c000001fed2f7d80] [c00000000011f9a8] .cpu_startup_entry+0x708/0x7a0
[c000001fed2f7ec0] [c00000000003cb6c] .start_secondary+0x36c/0x3a0
[c000001fed2f7f90] [c000000000008b6c] start_secondary_prolog+0x10/0x14

Fix this by converting kmem_cache_free trace point into TRACE_EVENT_CONDITION
where condition is cpu_online(smp_processor_id())

Signed-off-by: Shreyas B. Prabhu <[email protected]>
Reported-by: Aneesh Kumar K.V <[email protected]>
---
include/trace/events/kmem.h | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
index 81ea598..dd9e612 100644
--- a/include/trace/events/kmem.h
+++ b/include/trace/events/kmem.h
@@ -140,11 +140,13 @@ DEFINE_EVENT(kmem_free, kfree,
TP_ARGS(call_site, ptr)
);

-DEFINE_EVENT(kmem_free, kmem_cache_free,
+DEFINE_EVENT_CONDITION(kmem_free, kmem_cache_free,

TP_PROTO(unsigned long call_site, const void *ptr),

- TP_ARGS(call_site, ptr)
+ TP_ARGS(call_site, ptr),
+
+ TP_CONDITION(cpu_online(smp_processor_id()))
);

TRACE_EVENT(mm_page_free,
--
1.9.3


2015-04-28 15:51:55

by Shreyas B. Prabhu

[permalink] [raw]
Subject: [PATCH 2/3] tracing/mm: Don't trace mm_page_free on offline cpus

Since tracepoints use RCU for protection, they must not be called on
offline cpus. trace_mm_page_free can be called on an offline cpu in
this scenario caught by LOCKDEP:

===============================
[ INFO: suspicious RCU usage. ]
4.1.0-rc1+ #9 Not tainted
-------------------------------
include/trace/events/kmem.h:170 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

RCU used illegally from offline CPU!
rcu_scheduler_active = 1, debug_locks = 1
no locks held by swapper/1/0.

stack backtrace:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.1.0-rc1+ #9
Call Trace:
[c000001fed2f7790] [c0000000009dee8c] .dump_stack+0x98/0xd4 (unreliable)
[c000001fed2f7810] [c000000000128d88] .lockdep_rcu_suspicious+0x108/0x170
[c000001fed2f78a0] [c000000000203bc4] .free_pages_prepare+0x494/0x680
[c000001fed2f7980] [c000000000207fd0] .free_hot_cold_page+0x50/0x280
[c000001fed2f7a30] [c00000000004d000] .destroy_context+0x90/0xd0
[c000001fed2f7ab0] [c0000000000bd1d8] .__mmdrop+0x58/0x160
[c000001fed2f7b40] [c0000000001068e0] .idle_task_exit+0xf0/0x100
[c000001fed2f7bc0] [c000000000066948] .pnv_smp_cpu_kill_self+0x58/0x2c0
[c000001fed2f7ca0] [c00000000003ce34] .cpu_die+0x34/0x50
[c000001fed2f7d10] [c0000000000176d0] .arch_cpu_idle_dead+0x20/0x40
[c000001fed2f7d80] [c00000000011f9a8] .cpu_startup_entry+0x708/0x7a0
[c000001fed2f7ec0] [c00000000003cb6c] .start_secondary+0x36c/0x3a0
[c000001fed2f7f90] [c000000000008b6c] start_secondary_prolog+0x10/0x14

Fix this by converting mm_page_free trace point into TRACE_EVENT_CONDITION
where condition is cpu_online(smp_processor_id())

Signed-off-by: Shreyas B. Prabhu <[email protected]>
---
include/trace/events/kmem.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
index dd9e612..4abda92 100644
--- a/include/trace/events/kmem.h
+++ b/include/trace/events/kmem.h
@@ -149,12 +149,14 @@ DEFINE_EVENT_CONDITION(kmem_free, kmem_cache_free,
TP_CONDITION(cpu_online(smp_processor_id()))
);

-TRACE_EVENT(mm_page_free,
+TRACE_EVENT_CONDITION(mm_page_free,

TP_PROTO(struct page *page, unsigned int order),

TP_ARGS(page, order),

+ TP_CONDITION(cpu_online(smp_processor_id())),
+
TP_STRUCT__entry(
__field( unsigned long, pfn )
__field( unsigned int, order )
--
1.9.3

2015-04-28 15:51:58

by Shreyas B. Prabhu

[permalink] [raw]
Subject: [PATCH 3/3] tracing/mm: Don't trace mm_page_pcpu_drain on offline cpus

Since tracepoints use RCU for protection, they must not be called on
offline cpus. trace_mm_page_pcpu_drain can be called on an offline cpu
in this scenario caught by LOCKDEP:

===============================
[ INFO: suspicious RCU usage. ]
4.1.0-rc1+ #9 Not tainted
-------------------------------
include/trace/events/kmem.h:265 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

RCU used illegally from offline CPU!
rcu_scheduler_active = 1, debug_locks = 1
1 lock held by swapper/5/0:
#0: (&(&zone->lock)->rlock){..-...}, at: [<c0000000002073b0>] .free_pcppages_bulk+0x70/0x920

stack backtrace:
CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.1.0-rc1+ #9
Call Trace:
[c000001fed2e7720] [c0000000009dee8c] .dump_stack+0x98/0xd4 (unreliable)
[c000001fed2e77a0] [c000000000128d88] .lockdep_rcu_suspicious+0x108/0x170
[c000001fed2e7830] [c00000000020794c] .free_pcppages_bulk+0x60c/0x920
[c000001fed2e7980] [c000000000208188] .free_hot_cold_page+0x208/0x280
[c000001fed2e7a30] [c00000000004d000] .destroy_context+0x90/0xd0
[c000001fed2e7ab0] [c0000000000bd1d8] .__mmdrop+0x58/0x160
[c000001fed2e7b40] [c0000000001068e0] .idle_task_exit+0xf0/0x100
[c000001fed2e7bc0] [c000000000066948] .pnv_smp_cpu_kill_self+0x58/0x2c0
[c000001fed2e7ca0] [c00000000003ce34] .cpu_die+0x34/0x50
[c000001fed2e7d10] [c0000000000176d0] .arch_cpu_idle_dead+0x20/0x40
[c000001fed2e7d80] [c00000000011f9a8] .cpu_startup_entry+0x708/0x7a0
[c000001fed2e7ec0] [c00000000003cb6c] .start_secondary+0x36c/0x3a0
[c000001fed2e7f90] [c000000000008b6c] start_secondary_prolog+0x10/0x14

Fix this by converting mm_page_pcpu_drain trace point into TRACE_EVENT_CONDITION
where condition is cpu_online(smp_processor_id())

Signed-off-by: Shreyas B. Prabhu <[email protected]>
---
include/trace/events/kmem.h | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
index 4abda92..6cd975f 100644
--- a/include/trace/events/kmem.h
+++ b/include/trace/events/kmem.h
@@ -257,12 +257,26 @@ DEFINE_EVENT(mm_page, mm_page_alloc_zone_locked,
TP_ARGS(page, order, migratetype)
);

-DEFINE_EVENT_PRINT(mm_page, mm_page_pcpu_drain,
+TRACE_EVENT_CONDITION(mm_page_pcpu_drain,

TP_PROTO(struct page *page, unsigned int order, int migratetype),

TP_ARGS(page, order, migratetype),

+ TP_CONDITION(cpu_online(smp_processor_id())),
+
+ TP_STRUCT__entry(
+ __field( unsigned long, pfn )
+ __field( unsigned int, order )
+ __field( int, migratetype )
+ ),
+
+ TP_fast_assign(
+ __entry->pfn = page ? page_to_pfn(page) : -1UL;
+ __entry->order = order;
+ __entry->migratetype = migratetype;
+ ),
+
TP_printk("page=%p pfn=%lu order=%d migratetype=%d",
pfn_to_page(__entry->pfn), __entry->pfn,
__entry->order, __entry->migratetype)
--
1.9.3

2015-04-29 09:04:11

by Preeti Murthy

[permalink] [raw]
Subject: Re: [PATCH 1/3] tracing/mm: Don't trace kmem_cache_free on offline cpus

Ccing Paul,

On Tue, Apr 28, 2015 at 9:21 PM, Shreyas B. Prabhu
<[email protected]> wrote:
> Since tracepoints use RCU for protection, they must not be called on
> offline cpus. trace_kmem_cache_free can be called on an offline cpu in
> this scenario caught by LOCKDEP:
>
> ===============================
> [ INFO: suspicious RCU usage. ]
> 4.1.0-rc1+ #9 Not tainted
> -------------------------------
> include/trace/events/kmem.h:148 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
> RCU used illegally from offline CPU!
> rcu_scheduler_active = 1, debug_locks = 1
> no locks held by swapper/1/0.
>
> stack backtrace:
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.1.0-rc1+ #9
> Call Trace:
> [c000001fed2f78f0] [c0000000009dee8c] .dump_stack+0x98/0xd4 (unreliable)
> [c000001fed2f7970] [c000000000128d88] .lockdep_rcu_suspicious+0x108/0x170
> [c000001fed2f7a00] [c00000000026f924] .kmem_cache_free+0x344/0x4b0
> [c000001fed2f7ab0] [c0000000000bd1cc] .__mmdrop+0x4c/0x160
> [c000001fed2f7b40] [c0000000001068e0] .idle_task_exit+0xf0/0x100
> [c000001fed2f7bc0] [c000000000066948] .pnv_smp_cpu_kill_self+0x58/0x2c0
> [c000001fed2f7ca0] [c00000000003ce34] .cpu_die+0x34/0x50
> [c000001fed2f7d10] [c0000000000176d0] .arch_cpu_idle_dead+0x20/0x40
> [c000001fed2f7d80] [c00000000011f9a8] .cpu_startup_entry+0x708/0x7a0
> [c000001fed2f7ec0] [c00000000003cb6c] .start_secondary+0x36c/0x3a0
> [c000001fed2f7f90] [c000000000008b6c] start_secondary_prolog+0x10/0x14
>
> Fix this by converting kmem_cache_free trace point into TRACE_EVENT_CONDITION
> where condition is cpu_online(smp_processor_id())
>
> Signed-off-by: Shreyas B. Prabhu <[email protected]>
> Reported-by: Aneesh Kumar K.V <[email protected]>
> ---
> include/trace/events/kmem.h | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
> index 81ea598..dd9e612 100644
> --- a/include/trace/events/kmem.h
> +++ b/include/trace/events/kmem.h
> @@ -140,11 +140,13 @@ DEFINE_EVENT(kmem_free, kfree,
> TP_ARGS(call_site, ptr)
> );
>
> -DEFINE_EVENT(kmem_free, kmem_cache_free,
> +DEFINE_EVENT_CONDITION(kmem_free, kmem_cache_free,
>
> TP_PROTO(unsigned long call_site, const void *ptr),
>
> - TP_ARGS(call_site, ptr)
> + TP_ARGS(call_site, ptr),
> +
> + TP_CONDITION(cpu_online(smp_processor_id()))
> );
>
> TRACE_EVENT(mm_page_free,

Reviewed-by: Preeti U Murthy <[email protected]>

Regards
Preeti U Murthy
> --
> 1.9.3
>
> --
> 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/

2015-04-29 09:06:20

by Preeti Murthy

[permalink] [raw]
Subject: Re: [PATCH 2/3] tracing/mm: Don't trace mm_page_free on offline cpus

Ccing Paul,

On Tue, Apr 28, 2015 at 9:21 PM, Shreyas B. Prabhu
<[email protected]> wrote:
> Since tracepoints use RCU for protection, they must not be called on
> offline cpus. trace_mm_page_free can be called on an offline cpu in
> this scenario caught by LOCKDEP:
>
> ===============================
> [ INFO: suspicious RCU usage. ]
> 4.1.0-rc1+ #9 Not tainted
> -------------------------------
> include/trace/events/kmem.h:170 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
> RCU used illegally from offline CPU!
> rcu_scheduler_active = 1, debug_locks = 1
> no locks held by swapper/1/0.
>
> stack backtrace:
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.1.0-rc1+ #9
> Call Trace:
> [c000001fed2f7790] [c0000000009dee8c] .dump_stack+0x98/0xd4 (unreliable)
> [c000001fed2f7810] [c000000000128d88] .lockdep_rcu_suspicious+0x108/0x170
> [c000001fed2f78a0] [c000000000203bc4] .free_pages_prepare+0x494/0x680
> [c000001fed2f7980] [c000000000207fd0] .free_hot_cold_page+0x50/0x280
> [c000001fed2f7a30] [c00000000004d000] .destroy_context+0x90/0xd0
> [c000001fed2f7ab0] [c0000000000bd1d8] .__mmdrop+0x58/0x160
> [c000001fed2f7b40] [c0000000001068e0] .idle_task_exit+0xf0/0x100
> [c000001fed2f7bc0] [c000000000066948] .pnv_smp_cpu_kill_self+0x58/0x2c0
> [c000001fed2f7ca0] [c00000000003ce34] .cpu_die+0x34/0x50
> [c000001fed2f7d10] [c0000000000176d0] .arch_cpu_idle_dead+0x20/0x40
> [c000001fed2f7d80] [c00000000011f9a8] .cpu_startup_entry+0x708/0x7a0
> [c000001fed2f7ec0] [c00000000003cb6c] .start_secondary+0x36c/0x3a0
> [c000001fed2f7f90] [c000000000008b6c] start_secondary_prolog+0x10/0x14
>
> Fix this by converting mm_page_free trace point into TRACE_EVENT_CONDITION
> where condition is cpu_online(smp_processor_id())
>
> Signed-off-by: Shreyas B. Prabhu <[email protected]>
> ---
> include/trace/events/kmem.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
> index dd9e612..4abda92 100644
> --- a/include/trace/events/kmem.h
> +++ b/include/trace/events/kmem.h
> @@ -149,12 +149,14 @@ DEFINE_EVENT_CONDITION(kmem_free, kmem_cache_free,
> TP_CONDITION(cpu_online(smp_processor_id()))
> );
>
> -TRACE_EVENT(mm_page_free,
> +TRACE_EVENT_CONDITION(mm_page_free,
>
> TP_PROTO(struct page *page, unsigned int order),
>
> TP_ARGS(page, order),
>
> + TP_CONDITION(cpu_online(smp_processor_id())),
> +
> TP_STRUCT__entry(
> __field( unsigned long, pfn )
> __field( unsigned int, order )
> --

Reviewed-by: Preeti U Murthy <[email protected]>

Regards
Preeti U Murthy

> 1.9.3
>
> --
> 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/

2015-04-29 09:07:19

by Preeti Murthy

[permalink] [raw]
Subject: Re: [PATCH 2/3] tracing/mm: Don't trace mm_page_free on offline cpus

On Wed, Apr 29, 2015 at 2:36 PM, Preeti Murthy <[email protected]> wrote:
> Ccing Paul,
>
> On Tue, Apr 28, 2015 at 9:21 PM, Shreyas B. Prabhu
> <[email protected]> wrote:
>> Since tracepoints use RCU for protection, they must not be called on
>> offline cpus. trace_mm_page_free can be called on an offline cpu in
>> this scenario caught by LOCKDEP:
>>
>> ===============================
>> [ INFO: suspicious RCU usage. ]
>> 4.1.0-rc1+ #9 Not tainted
>> -------------------------------
>> include/trace/events/kmem.h:170 suspicious rcu_dereference_check() usage!
>>
>> other info that might help us debug this:
>>
>> RCU used illegally from offline CPU!
>> rcu_scheduler_active = 1, debug_locks = 1
>> no locks held by swapper/1/0.
>>
>> stack backtrace:
>> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.1.0-rc1+ #9
>> Call Trace:
>> [c000001fed2f7790] [c0000000009dee8c] .dump_stack+0x98/0xd4 (unreliable)
>> [c000001fed2f7810] [c000000000128d88] .lockdep_rcu_suspicious+0x108/0x170
>> [c000001fed2f78a0] [c000000000203bc4] .free_pages_prepare+0x494/0x680
>> [c000001fed2f7980] [c000000000207fd0] .free_hot_cold_page+0x50/0x280
>> [c000001fed2f7a30] [c00000000004d000] .destroy_context+0x90/0xd0
>> [c000001fed2f7ab0] [c0000000000bd1d8] .__mmdrop+0x58/0x160
>> [c000001fed2f7b40] [c0000000001068e0] .idle_task_exit+0xf0/0x100
>> [c000001fed2f7bc0] [c000000000066948] .pnv_smp_cpu_kill_self+0x58/0x2c0
>> [c000001fed2f7ca0] [c00000000003ce34] .cpu_die+0x34/0x50
>> [c000001fed2f7d10] [c0000000000176d0] .arch_cpu_idle_dead+0x20/0x40
>> [c000001fed2f7d80] [c00000000011f9a8] .cpu_startup_entry+0x708/0x7a0
>> [c000001fed2f7ec0] [c00000000003cb6c] .start_secondary+0x36c/0x3a0
>> [c000001fed2f7f90] [c000000000008b6c] start_secondary_prolog+0x10/0x14
>>
>> Fix this by converting mm_page_free trace point into TRACE_EVENT_CONDITION
>> where condition is cpu_online(smp_processor_id())
>>
>> Signed-off-by: Shreyas B. Prabhu <[email protected]>
>> ---
>> include/trace/events/kmem.h | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
>> index dd9e612..4abda92 100644
>> --- a/include/trace/events/kmem.h
>> +++ b/include/trace/events/kmem.h
>> @@ -149,12 +149,14 @@ DEFINE_EVENT_CONDITION(kmem_free, kmem_cache_free,
>> TP_CONDITION(cpu_online(smp_processor_id()))
>> );
>>
>> -TRACE_EVENT(mm_page_free,
>> +TRACE_EVENT_CONDITION(mm_page_free,
>>
>> TP_PROTO(struct page *page, unsigned int order),
>>
>> TP_ARGS(page, order),
>>
>> + TP_CONDITION(cpu_online(smp_processor_id())),
>> +
>> TP_STRUCT__entry(
>> __field( unsigned long, pfn )
>> __field( unsigned int, order )
>> --
>
> Reviewed-by: Preeti U Murthy <[email protected]>
>
> Regards
> Preeti U Murthy
>
>> 1.9.3
>>
>> --
>> 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/

2015-04-29 09:13:58

by Preeti Murthy

[permalink] [raw]
Subject: Re: [PATCH 3/3] tracing/mm: Don't trace mm_page_pcpu_drain on offline cpus

Ccing Paul,

On Tue, Apr 28, 2015 at 9:21 PM, Shreyas B. Prabhu
<[email protected]> wrote:
> Since tracepoints use RCU for protection, they must not be called on
> offline cpus. trace_mm_page_pcpu_drain can be called on an offline cpu
> in this scenario caught by LOCKDEP:
>
> ===============================
> [ INFO: suspicious RCU usage. ]
> 4.1.0-rc1+ #9 Not tainted
> -------------------------------
> include/trace/events/kmem.h:265 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
> RCU used illegally from offline CPU!
> rcu_scheduler_active = 1, debug_locks = 1
> 1 lock held by swapper/5/0:
> #0: (&(&zone->lock)->rlock){..-...}, at: [<c0000000002073b0>] .free_pcppages_bulk+0x70/0x920
>
> stack backtrace:
> CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.1.0-rc1+ #9
> Call Trace:
> [c000001fed2e7720] [c0000000009dee8c] .dump_stack+0x98/0xd4 (unreliable)
> [c000001fed2e77a0] [c000000000128d88] .lockdep_rcu_suspicious+0x108/0x170
> [c000001fed2e7830] [c00000000020794c] .free_pcppages_bulk+0x60c/0x920
> [c000001fed2e7980] [c000000000208188] .free_hot_cold_page+0x208/0x280
> [c000001fed2e7a30] [c00000000004d000] .destroy_context+0x90/0xd0
> [c000001fed2e7ab0] [c0000000000bd1d8] .__mmdrop+0x58/0x160
> [c000001fed2e7b40] [c0000000001068e0] .idle_task_exit+0xf0/0x100
> [c000001fed2e7bc0] [c000000000066948] .pnv_smp_cpu_kill_self+0x58/0x2c0
> [c000001fed2e7ca0] [c00000000003ce34] .cpu_die+0x34/0x50
> [c000001fed2e7d10] [c0000000000176d0] .arch_cpu_idle_dead+0x20/0x40
> [c000001fed2e7d80] [c00000000011f9a8] .cpu_startup_entry+0x708/0x7a0
> [c000001fed2e7ec0] [c00000000003cb6c] .start_secondary+0x36c/0x3a0
> [c000001fed2e7f90] [c000000000008b6c] start_secondary_prolog+0x10/0x14
>
> Fix this by converting mm_page_pcpu_drain trace point into TRACE_EVENT_CONDITION
> where condition is cpu_online(smp_processor_id())
>
> Signed-off-by: Shreyas B. Prabhu <[email protected]>
> ---
> include/trace/events/kmem.h | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
> index 4abda92..6cd975f 100644
> --- a/include/trace/events/kmem.h
> +++ b/include/trace/events/kmem.h
> @@ -257,12 +257,26 @@ DEFINE_EVENT(mm_page, mm_page_alloc_zone_locked,
> TP_ARGS(page, order, migratetype)
> );
>
> -DEFINE_EVENT_PRINT(mm_page, mm_page_pcpu_drain,
> +TRACE_EVENT_CONDITION(mm_page_pcpu_drain,
>
> TP_PROTO(struct page *page, unsigned int order, int migratetype),
>
> TP_ARGS(page, order, migratetype),
>
> + TP_CONDITION(cpu_online(smp_processor_id())),
> +
> + TP_STRUCT__entry(
> + __field( unsigned long, pfn )
> + __field( unsigned int, order )
> + __field( int, migratetype )
> + ),
> +
> + TP_fast_assign(
> + __entry->pfn = page ? page_to_pfn(page) : -1UL;
> + __entry->order = order;
> + __entry->migratetype = migratetype;
> + ),
> +

What was the need to do the above changes besides adding TP_CONDITION ?

Regards
Preeti U Murthy

2015-04-29 14:49:37

by Shreyas B. Prabhu

[permalink] [raw]
Subject: Re: [PATCH 3/3] tracing/mm: Don't trace mm_page_pcpu_drain on offline cpus


>> -DEFINE_EVENT_PRINT(mm_page, mm_page_pcpu_drain,
>> +TRACE_EVENT_CONDITION(mm_page_pcpu_drain,
>>
>> TP_PROTO(struct page *page, unsigned int order, int migratetype),
>>
>> TP_ARGS(page, order, migratetype),
>>
>> + TP_CONDITION(cpu_online(smp_processor_id())),
>> +
>> + TP_STRUCT__entry(
>> + __field( unsigned long, pfn )
>> + __field( unsigned int, order )
>> + __field( int, migratetype )
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->pfn = page ? page_to_pfn(page) : -1UL;
>> + __entry->order = order;
>> + __entry->migratetype = migratetype;
>> + ),
>> +
>
> What was the need to do the above changes besides adding TP_CONDITION ?
>

IIUC there is no existing macro which can both add a condition and
override printk format, hence the fall back to TRACE_EVENT_CONDITION.

Thanks,
Shreyas

2015-04-29 15:18:48

by Steven Rostedt

[permalink] [raw]
Subject: Re: [PATCH 3/3] tracing/mm: Don't trace mm_page_pcpu_drain on offline cpus

On Wed, 29 Apr 2015 20:19:28 +0530
Shreyas B Prabhu <[email protected]> wrote:

> IIUC there is no existing macro which can both add a condition and
> override printk format, hence the fall back to TRACE_EVENT_CONDITION.

Hmm, want me to send you a patch that changes that?

-- Steve

2015-04-29 15:59:41

by Shreyas B. Prabhu

[permalink] [raw]
Subject: Re: [PATCH 3/3] tracing/mm: Don't trace mm_page_pcpu_drain on offline cpus



On Wednesday 29 April 2015 08:48 PM, Steven Rostedt wrote:
> On Wed, 29 Apr 2015 20:19:28 +0530
> Shreyas B Prabhu <[email protected]> wrote:
>
>> IIUC there is no existing macro which can both add a condition and
>> override printk format, hence the fall back to TRACE_EVENT_CONDITION.
>
> Hmm, want me to send you a patch that changes that?
>
I am not sure if its worth the effort now. It doesn't look like any
other trace point apart from the above use case will benefit from it.
Only smbus_write and smbus_reply seem to come close. But even they need
separate TP_fast_assign.

Thanks,
Shreyas

2015-04-29 17:08:59

by Steven Rostedt

[permalink] [raw]
Subject: Re: [PATCH 3/3] tracing/mm: Don't trace mm_page_pcpu_drain on offline cpus

On Wed, 29 Apr 2015 21:28:38 +0530
Shreyas B Prabhu <[email protected]> wrote:

>
>
> On Wednesday 29 April 2015 08:48 PM, Steven Rostedt wrote:
> > On Wed, 29 Apr 2015 20:19:28 +0530
> > Shreyas B Prabhu <[email protected]> wrote:
> >
> >> IIUC there is no existing macro which can both add a condition and
> >> override printk format, hence the fall back to TRACE_EVENT_CONDITION.
> >
> > Hmm, want me to send you a patch that changes that?
> >
> I am not sure if its worth the effort now. It doesn't look like any
> other trace point apart from the above use case will benefit from it.
> Only smbus_write and smbus_reply seem to come close. But even they need
> separate TP_fast_assign.

It shouldn't be a problem to implement. But I'm currently cleaning up
those files, and any changes will cause nasty conflicts.

Lets do this. Push the current changes as is, and when I get around to
adding a DEFINE_EVENT_PRINT_CONDITION(), we can modify that code to use
it.

-- Steve

2015-04-29 17:20:51

by Shreyas B. Prabhu

[permalink] [raw]
Subject: Re: [PATCH 3/3] tracing/mm: Don't trace mm_page_pcpu_drain on offline cpus



On Wednesday 29 April 2015 10:38 PM, Steven Rostedt wrote:
>> I am not sure if its worth the effort now. It doesn't look like any
>> other trace point apart from the above use case will benefit from it.
>> Only smbus_write and smbus_reply seem to come close. But even they need
>> separate TP_fast_assign.
>
> It shouldn't be a problem to implement. But I'm currently cleaning up
> those files, and any changes will cause nasty conflicts.
>
> Lets do this. Push the current changes as is, and when I get around to
> adding a DEFINE_EVENT_PRINT_CONDITION(), we can modify that code to use
> it.
>
Okay, sure.

Thanks,
Shreyas

2015-04-30 04:36:08

by Preeti Murthy

[permalink] [raw]
Subject: Re: [PATCH 3/3] tracing/mm: Don't trace mm_page_pcpu_drain on offline cpus

On Wed, Apr 29, 2015 at 10:49 PM, Shreyas B Prabhu
<[email protected]> wrote:
>
>
> On Wednesday 29 April 2015 10:38 PM, Steven Rostedt wrote:
>>> I am not sure if its worth the effort now. It doesn't look like any
>>> other trace point apart from the above use case will benefit from it.
>>> Only smbus_write and smbus_reply seem to come close. But even they need
>>> separate TP_fast_assign.
>>
>> It shouldn't be a problem to implement. But I'm currently cleaning up
>> those files, and any changes will cause nasty conflicts.
>>
>> Lets do this. Push the current changes as is, and when I get around to
>> adding a DEFINE_EVENT_PRINT_CONDITION(), we can modify that code to use
>> it.
>>
> Okay, sure.

Looks good then.

Reviewed-by: Preeti U Murthy <[email protected]>
>
> Thanks,
> Shreyas
>

2015-04-30 04:42:36

by Shreyas B. Prabhu

[permalink] [raw]
Subject: Re: [PATCH 3/3] tracing/mm: Don't trace mm_page_pcpu_drain on offline cpus



On Thursday 30 April 2015 10:06 AM, Preeti Murthy wrote:
> On Wed, Apr 29, 2015 at 10:49 PM, Shreyas B Prabhu
> <[email protected]> wrote:
>>
>>
>> On Wednesday 29 April 2015 10:38 PM, Steven Rostedt wrote:
>>>> I am not sure if its worth the effort now. It doesn't look like any
>>>> other trace point apart from the above use case will benefit from it.
>>>> Only smbus_write and smbus_reply seem to come close. But even they need
>>>> separate TP_fast_assign.
>>>
>>> It shouldn't be a problem to implement. But I'm currently cleaning up
>>> those files, and any changes will cause nasty conflicts.
>>>
>>> Lets do this. Push the current changes as is, and when I get around to
>>> adding a DEFINE_EVENT_PRINT_CONDITION(), we can modify that code to use
>>> it.
>>>
>> Okay, sure.
>
> Looks good then.
>
> Reviewed-by: Preeti U Murthy <[email protected]>

Thanks a lot!

2015-05-08 04:38:14

by Shreyas B. Prabhu

[permalink] [raw]
Subject: Re: [PATCH 3/3] tracing/mm: Don't trace mm_page_pcpu_drain on offline cpus



On Wednesday 29 April 2015 10:38 PM, Steven Rostedt wrote:
> On Wed, 29 Apr 2015 21:28:38 +0530
> Shreyas B Prabhu <[email protected]> wrote:
>
>>
>>
>> On Wednesday 29 April 2015 08:48 PM, Steven Rostedt wrote:
>>> On Wed, 29 Apr 2015 20:19:28 +0530
>>> Shreyas B Prabhu <[email protected]> wrote:
>>>
>>>> IIUC there is no existing macro which can both add a condition and
>>>> override printk format, hence the fall back to TRACE_EVENT_CONDITION.
>>>
>>> Hmm, want me to send you a patch that changes that?
>>>
>> I am not sure if its worth the effort now. It doesn't look like any
>> other trace point apart from the above use case will benefit from it.
>> Only smbus_write and smbus_reply seem to come close. But even they need
>> separate TP_fast_assign.
>
> It shouldn't be a problem to implement. But I'm currently cleaning up
> those files, and any changes will cause nasty conflicts.
>
> Lets do this. Push the current changes as is, and when I get around to
> adding a DEFINE_EVENT_PRINT_CONDITION(), we can modify that code to use
> it.
>

Hi Steve,
Do you have any other suggestions for this patchset or will you take
them as is?

Thanks,
Shreyas

2015-05-08 14:18:22

by Steven Rostedt

[permalink] [raw]
Subject: Re: [PATCH 3/3] tracing/mm: Don't trace mm_page_pcpu_drain on offline cpus

On Fri, 08 May 2015 10:07:15 +0530
Shreyas B Prabhu <[email protected]> wrote:


> Hi Steve,
> Do you have any other suggestions for this patchset or will you take
> them as is?

I'm fine with them (add my Acked-by), but I don't usually pull in
changes for include/trace/events/*.h files. Those are usually maintained
by the creators of the files (subsystems they represent).

But I could pull them in if need be.

-- Steve

2015-05-08 16:40:47

by Shreyas B. Prabhu

[permalink] [raw]
Subject: Re: [PATCH 3/3] tracing/mm: Don't trace mm_page_pcpu_drain on offline cpus



On Friday 08 May 2015 07:48 PM, Steven Rostedt wrote:
> On Fri, 08 May 2015 10:07:15 +0530
> Shreyas B Prabhu <[email protected]> wrote:
>
>
>> Hi Steve,
>> Do you have any other suggestions for this patchset or will you take
>> them as is?
>
> I'm fine with them (add my Acked-by), but I don't usually pull in
> changes for include/trace/events/*.h files. Those are usually maintained
> by the creators of the files (subsystems they represent).
>
Oh I didn't know that. Let me resend the patches with your Acked-by,
this time cc'ing people who have added/edited the events.

Thanks,
Shreyas