Re: [RFC] scripts: Include postprocessing script for memory allocation tracing

> On Oct 21, 2016, at 3:08 AM, Michal Hocko wrote: > > Interesting. > $ cat /debug/tracing/available_tracers > function_graph preemptirqsoff preemptoff irqsoff function nop > > Do I have to configure anything specially? And if I do why isn't it any > better to simply add a

Re: [RFC] scripts: Include postprocessing script for memory allocation tracing

> On Oct 21, 2016, at 3:08 AM, Michal Hocko wrote: > > Interesting. > $ cat /debug/tracing/available_tracers > function_graph preemptirqsoff preemptoff irqsoff function nop > > Do I have to configure anything specially? And if I do why isn't it any > better to simply add a start tracepoint

Re: [RFC] scripts: Include postprocessing script for memory allocation tracing

Michal, > On Oct 18, 2016, at 8:13 AM, Michal Hocko wrote: > >> > > yes, function_graph tracer will give you _some_ information but it will > not have the context you are looking for, right? See the following > example > > -- > 0)

Re: [RFC] scripts: Include postprocessing script for memory allocation tracing

Michal, > On Oct 18, 2016, at 8:13 AM, Michal Hocko wrote: > >> > > yes, function_graph tracer will give you _some_ information but it will > not have the context you are looking for, right? See the following > example > > -- > 0) x-www-b-22756 =>

Re: [RFC] scripts: Include postprocessing script for memory allocation tracing

> On Oct 11, 2016, at 10:43 AM, Janani Ravichandran <janani.rvchn...@gmail.com> > wrote: > > Alright. I’ll add a starting tracepoint, change the script accordingly and > send a v2. Thanks! > I looked at it again and I think that the context information we ne

Re: [RFC] scripts: Include postprocessing script for memory allocation tracing

> On Oct 11, 2016, at 10:43 AM, Janani Ravichandran > wrote: > > Alright. I’ll add a starting tracepoint, change the script accordingly and > send a v2. Thanks! > I looked at it again and I think that the context information we need can be obtained from the tracepoint t

Re: [RFC] scripts: Include postprocessing script for memory allocation tracing

Hi Michal, > Extremely sorry for the delayed response. > Then I really think that we need a starting trace point. I think that > having the full context information is really helpful in order to > understand latencies induced by allocations. > — Alright. I’ll add a starting tracepoint, change

Re: [RFC] scripts: Include postprocessing script for memory allocation tracing

Hi Michal, > Extremely sorry for the delayed response. > Then I really think that we need a starting trace point. I think that > having the full context information is really helpful in order to > understand latencies induced by allocations. > — Alright. I’ll add a starting tracepoint, change

Re: [RFC] scripts: Include postprocessing script for memory allocation tracing

> On Sep 19, 2016, at 5:42 AM, Michal Hocko <mho...@kernel.org> wrote: > > On Tue 13-09-16 14:04:49, Janani Ravichandran wrote: >> >>> On Sep 12, 2016, at 8:16 AM, Michal Hocko <mho...@kernel.org> wrote: >> >> I’m using the function graph tracer

Re: [RFC] scripts: Include postprocessing script for memory allocation tracing

> On Sep 19, 2016, at 5:42 AM, Michal Hocko wrote: > > On Tue 13-09-16 14:04:49, Janani Ravichandran wrote: >> >>> On Sep 12, 2016, at 8:16 AM, Michal Hocko wrote: >> >> I’m using the function graph tracer to see how long __alloc_pages_nodemask() >&g

Re: [RFC] scripts: Include postprocessing script for memory allocation tracing

> set_ftrace_filter in setup_alloc_trace.sh sets __alloc_pages_nodemask as a function graph filter and this should help us observe how long the function took. > > On Sun 11-09-16 18:24:12, Janani Ravichandran wrote: > [...] >> allocation_postprocess.py is a script which reads from trace_pipe. It

Re: [RFC] scripts: Include postprocessing script for memory allocation tracing

up_alloc_trace.sh sets __alloc_pages_nodemask as a function graph filter and this should help us observe how long the function took. > > On Sun 11-09-16 18:24:12, Janani Ravichandran wrote: > [...] >> allocation_postprocess.py is a script which reads from trace_pipe. It >&g

[RFC] scripts: Include postprocessing script for memory allocation tracing

eas/ comments/ suggestions are welcome, escpecially on adherence to the python coding style followed by the Linux community and the functions enabled to be traced. Thanks. Signed-off-by: Janani Ravichandran <janani.rvchn...@gmail.com> --- scripts/tracing/allocation_postprocess

[RFC] scripts: Include postprocessing script for memory allocation tracing

eas/ comments/ suggestions are welcome, escpecially on adherence to the python coding style followed by the Linux community and the functions enabled to be traced. Thanks. Signed-off-by: Janani Ravichandran --- scripts/tracing/allocation_postprocess.py | 267 ++ scri

[RFC] scripts: Include postprocessing script for memory allocation tracing

eas/ comments/ suggestions are welcome, escpecially on adherence to the python coding style followed by the Linux community and the functions enabled to be traced. Thanks. Signed-off-by: Janani Ravichandran <janani.rvchn...@gmail.com> --- scripts/tracing/allocation_postprocess

[RFC] scripts: Include postprocessing script for memory allocation tracing

eas/ comments/ suggestions are welcome, escpecially on adherence to the python coding style followed by the Linux community and the functions enabled to be traced. Thanks. Signed-off-by: Janani Ravichandran --- scripts/tracing/allocation_postprocess.py | 267 ++ scri

[PATCH v2 2/2] fs: super.c: Add tracepoint to get name of superblock shrinker

/tmpfs 21588ns On line 5,we can see that there were times when the super_cache_scan callback wasn't invoked and therefore no name information was obtained. Signed-off-by: Janani Ravichandran <janani.rvchn...@gmail.com> --- Changes since v1: v1 did not have any mechanism to print names of sp

[PATCH v2 2/2] fs: super.c: Add tracepoint to get name of superblock shrinker

/tmpfs 21588ns On line 5,we can see that there were times when the super_cache_scan callback wasn't invoked and therefore no name information was obtained. Signed-off-by: Janani Ravichandran --- Changes since v1: v1 did not have any mechanism to print names of specific superblock types

[PATCH v2 1/2] include: trace: Display names of shrinker callbacks

This patch enables the names of callbacks in mm_shrink_slab_start and mm_shrink_slab_end to be seen by userspace tools. This should give some information regarding the identity of the shrinkers being run. Signed-off-by: Janani Ravichandran <janani.rvchn...@gmail.com> --- include/trace/

[PATCH v2 1/2] include: trace: Display names of shrinker callbacks

This patch enables the names of callbacks in mm_shrink_slab_start and mm_shrink_slab_end to be seen by userspace tools. This should give some information regarding the identity of the shrinkers being run. Signed-off-by: Janani Ravichandran --- include/trace/events/vmscan.h | 18

[PATCH v2 0/2] Get callbacks/names of shrinkers from tracepoints

for their suggestions. Janani Ravichandran (2): include: trace: Display names of shrinker callbacks fs: super.c: Add tracepoint to get name of superblock shrinker fs/super.c| 2 ++ include/trace/events/vmscan.h | 39 +-- 2 files changed, 39 insertions

[PATCH v2 0/2] Get callbacks/names of shrinkers from tracepoints

for their suggestions. Janani Ravichandran (2): include: trace: Display names of shrinker callbacks fs: super.c: Add tracepoint to get name of superblock shrinker fs/super.c| 2 ++ include/trace/events/vmscan.h | 39 +-- 2 files changed, 39 insertions

Re: [PATCH 2/2] mm: compaction.c: Add/Modify direct compaction tracepoints

> On Aug 1, 2016, at 6:55 PM, Vlastimil Babka wrote: > > > Yea, this tracepoint has been odd in not printing node/zone in a friendly way > (it's possible to determine it from zone_start/zone_end though, so this is > good in general. But instead of printing nid and zid like

Re: [PATCH 2/2] mm: compaction.c: Add/Modify direct compaction tracepoints

> On Aug 1, 2016, at 6:55 PM, Vlastimil Babka wrote: > > > Yea, this tracepoint has been odd in not printing node/zone in a friendly way > (it's possible to determine it from zone_start/zone_end though, so this is > good in general. But instead of printing nid and zid like this, it would be

Re: [PATCH 1/2] mm: page_alloc.c: Add tracepoints for slowpath

> On Aug 5, 2016, at 10:00 PM, Steven Rostedt wrote: > >> > > You probably want to clear the trace here, or set function_graph here > first. Because the function graph starts writing to the buffer > immediately. > I did that, just didn’t include it here :) >> > > When

Re: [PATCH 1/2] mm: page_alloc.c: Add tracepoints for slowpath

> On Aug 5, 2016, at 10:00 PM, Steven Rostedt wrote: > >> > > You probably want to clear the trace here, or set function_graph here > first. Because the function graph starts writing to the buffer > immediately. > I did that, just didn’t include it here :) >> > > When threshold is set,

Re: [PATCH 1/2] mm: page_alloc.c: Add tracepoints for slowpath

> On Aug 4, 2016, at 8:49 PM, Steven Rostedt <rost...@goodmis.org> wrote: > > On Fri, 29 Jul 2016 01:41:20 +0530 > Janani Ravichandran <janani.rvchn...@gmail.com> wrote: > > Sorry for the late reply, I've been swamped with other things since > coming back

Re: [PATCH 1/2] mm: page_alloc.c: Add tracepoints for slowpath

> On Aug 4, 2016, at 8:49 PM, Steven Rostedt wrote: > > On Fri, 29 Jul 2016 01:41:20 +0530 > Janani Ravichandran wrote: > > Sorry for the late reply, I've been swamped with other things since > coming back from my vacation. > No problem! > > Hmm, looking a

Re: [PATCH 1/2] mm: page_alloc.c: Add tracepoints for slowpath

> On Jul 27, 2016, at 8:53 PM, Steven Rostedt wrote: > > I'm thinking you only need one tracepoint, and use function_graph > tracer for the length of the function call. > > # cd /sys/kernel/debug/tracing > # echo __alloc_pages_nodemask > set_ftrace_filter > # echo

Re: [PATCH 1/2] mm: page_alloc.c: Add tracepoints for slowpath

> On Jul 27, 2016, at 8:53 PM, Steven Rostedt wrote: > > I'm thinking you only need one tracepoint, and use function_graph > tracer for the length of the function call. > > # cd /sys/kernel/debug/tracing > # echo __alloc_pages_nodemask > set_ftrace_filter > # echo function_graph >

[PATCH 2/2] mm: compaction.c: Add/Modify direct compaction tracepoints

Add zone information to an existing tracepoint in compact_zone(). Also, add a new tracepoint at the end of the compaction code so that latency information can be derived. Signed-off-by: Janani Ravichandran <janani.rvchn...@gmail.com> --- include/trace/events/compaction.

[PATCH 2/2] mm: compaction.c: Add/Modify direct compaction tracepoints

Add zone information to an existing tracepoint in compact_zone(). Also, add a new tracepoint at the end of the compaction code so that latency information can be derived. Signed-off-by: Janani Ravichandran --- include/trace/events/compaction.h | 38 +- mm

[PATCH 1/2] mm: page_alloc.c: Add tracepoints for slowpath

Add tracepoints to the slowpath code to gather some information. The tracepoints can also be used to find out how much time was spent in the slowpath. Signed-off-by: Janani Ravichandran <janani.rvchn...@gmail.com> --- include/trace/events/kmem.h | 40 ++

[PATCH 1/2] mm: page_alloc.c: Add tracepoints for slowpath

Add tracepoints to the slowpath code to gather some information. The tracepoints can also be used to find out how much time was spent in the slowpath. Signed-off-by: Janani Ravichandran --- include/trace/events/kmem.h | 40 mm/page_alloc.c

[PATCH 0/2] New tracepoints for slowpath and memory compaction

some zone information that may be useful. Janani Ravichandran (2): mm: page_alloc.c: Add tracepoints for slowpath mm: compaction.c: Add/Modify direct compaction tracepoints include/trace/events/compaction.h | 38 - include/trace/events/kmem.h | 40

[PATCH 0/2] New tracepoints for slowpath and memory compaction

some zone information that may be useful. Janani Ravichandran (2): mm: page_alloc.c: Add tracepoints for slowpath mm: compaction.c: Add/Modify direct compaction tracepoints include/trace/events/compaction.h | 38 - include/trace/events/kmem.h | 40

Re: [PATCH 1/3] Add a new field to struct shrinker

> On Jul 11, 2016, at 8:03 PM, Michal Hocko wrote: > > On Mon 11-07-16 10:12:51, Rik van Riel wrote: >> >> What mechanism do you have in mind for obtaining the name, >> Michal? > > Not sure whether tracing infrastructure allows printk like %ps. If not > then it doesn't

Re: [PATCH 1/3] Add a new field to struct shrinker

> On Jul 11, 2016, at 8:03 PM, Michal Hocko wrote: > > On Mon 11-07-16 10:12:51, Rik van Riel wrote: >> >> What mechanism do you have in mind for obtaining the name, >> Michal? > > Not sure whether tracing infrastructure allows printk like %ps. If not > then it doesn't sound too hard to add.

Re: [PATCH 3/3] Add name fields in shrinker tracepoint definitions

> On Jul 13, 2016, at 6:05 AM, Tony Jones <to...@suse.de> wrote: > > On 07/11/2016 07:18 AM, Vlastimil Babka wrote: >> On 07/09/2016 11:05 AM, Janani Ravichandran wrote: >>> >>> TP_fast_assign( >>> + __entry->n

Re: [PATCH 3/3] Add name fields in shrinker tracepoint definitions

> On Jul 13, 2016, at 6:05 AM, Tony Jones wrote: > > On 07/11/2016 07:18 AM, Vlastimil Babka wrote: >> On 07/09/2016 11:05 AM, Janani Ravichandran wrote: >>> >>> TP_fast_assign( >>> + __entry->name = shr->name; >>>

[PATCH 3/3] Add name fields in shrinker tracepoint definitions

Currently, the mm_shrink_slab_start and mm_shrink_slab_end tracepoints tell us how much time was spent in a shrinker, the number of objects scanned, etc. But there is no information about the identity of the shrinker. This patch enables the trace output to display names of shrinkers. ---

[PATCH 3/3] Add name fields in shrinker tracepoint definitions

Currently, the mm_shrink_slab_start and mm_shrink_slab_end tracepoints tell us how much time was spent in a shrinker, the number of objects scanned, etc. But there is no information about the identity of the shrinker. This patch enables the trace output to display names of shrinkers. ---

[PATCH 2/3] Update name field for all shrinker instances

This patch makes changes to have all instances of struct shrinker update the newly added name field. This name could then be passed to tracepoints, which can help identify which shrinker was invoked. --- arch/x86/kvm/mmu.c | 1 +

[PATCH 2/3] Update name field for all shrinker instances

This patch makes changes to have all instances of struct shrinker update the newly added name field. This name could then be passed to tracepoints, which can help identify which shrinker was invoked. --- arch/x86/kvm/mmu.c | 1 +

[PATCH 1/3] Add a new field to struct shrinker

Struct shrinker does not have a field to uniquely identify the shrinkers it represents. It would be helpful to have a new field to hold names of shrinkers. This information would be useful while analyzing their behavior using tracepoints. --- include/linux/shrinker.h | 1 + 1 file changed, 1

[PATCH 1/3] Add a new field to struct shrinker

Struct shrinker does not have a field to uniquely identify the shrinkers it represents. It would be helpful to have a new field to hold names of shrinkers. This information would be useful while analyzing their behavior using tracepoints. --- include/linux/shrinker.h | 1 + 1 file changed, 1

[PATCH 0/3] Add names of shrinkers and have tracepoints display them

ext4_es_shrinker : 0.954 ms workingset_shadow_shrinker : 1.091 ms deferred_split_shrinker : 6.043 ms super_cache_shrinker : 84.218 ms total time spent in shrinkers = 92.472 ms This shows the various shrinkers called and the times spent. Janani Ravichandran (3): Add a new field to struct shrinker Update

[PATCH 0/3] Add names of shrinkers and have tracepoints display them

ext4_es_shrinker : 0.954 ms workingset_shadow_shrinker : 1.091 ms deferred_split_shrinker : 6.043 ms super_cache_shrinker : 84.218 ms total time spent in shrinkers = 92.472 ms This shows the various shrinkers called and the times spent. Janani Ravichandran (3): Add a new field to struct shrinker Update