> 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.
> 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
llect
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
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
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
> 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 > current_trace
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
>> do
> 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, look
> 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, the
> 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
> 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;
>>>
> 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 and
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
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 => x-t
66 ms
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
U
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 inse
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 +
drivers/gpu/drm/i915/i915_gem_shrin
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.
---
include/
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
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
_scan/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
ty
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
> 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 trac
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
24 matches
Mail list logo
