-by: Chenggang Qin
---
tools/perf/builtin-report.c |5 +
tools/perf/util/session.c |3 +++
tools/perf/util/session.h |2 ++
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index e9e9d0a..d3c1c8a 100644
--- a/tools
-by: Chenggang Qin
---
tools/perf/util/session.c | 43 +--
1 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 4e9dd66..d50e29e 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util
rton
Signed-off-by: Chenggang Qin
---
tools/perf/builtin-report.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 72eae74..e9e9d0a 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/bui
Cc: Wu Fengguang
Cc: Mike Galbraith
Cc: Andrew Morton
Signed-off-by: Chenggang Qin
---
tools/perf/util/session.c |3 +++
tools/perf/util/session.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 193b
: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Arjan van de Ven
Cc: Namhyung Kim
Cc: Yanmin Zhang
Cc: Wu Fengguang
Cc: Mike Galbraith
Cc: Andrew Morton
Signed-off-by: Chenggang Qin
Chenggang Qin (4):
perf tools: add parameter 'start' & 'end' to perf report
perf tools: relate 'start' &a
From: Chenggang Qin
perf_session_free_sample_buffers() can be removed from
__perf_session__process_pipe_events(), since the ordered_samples buffer is not
used while samples are read from the pipe.
__perf_session__process_pipe_events() is only used while process the events from
pipe. While
From: Chenggang Qin chenggang@taobao.com
perf_session_free_sample_buffers() can be removed from
__perf_session__process_pipe_events(), since the ordered_samples buffer is not
used while samples are read from the pipe.
__perf_session__process_pipe_events() is only used while process the events
: Mike Galbraith efa...@gmx.de
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Chenggang Qin chenggang@taobao.com
Chenggang Qin (4):
perf tools: add parameter 'start' 'end' to perf report
perf tools: relate 'start' 'end' to perf_session
perf tools: record min_timestamp of samples
...@linux.intel.com
Cc: Namhyung Kim namhy...@gmail.com
Cc: Yanmin Zhang yanmin.zh...@intel.com
Cc: Wu Fengguang fengguang...@intel.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Chenggang Qin chenggang@taobao.com
---
tools/perf/util/session.c | 43
ar...@linux.intel.com
Cc: Namhyung Kim namhy...@gmail.com
Cc: Yanmin Zhang yanmin.zh...@intel.com
Cc: Wu Fengguang fengguang...@intel.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Chenggang Qin chenggang@taobao.com
---
tools/perf/builtin
Cc: Namhyung Kim namhy...@gmail.com
Cc: Yanmin Zhang yanmin.zh...@intel.com
Cc: Wu Fengguang fengguang...@intel.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Chenggang Qin chenggang@taobao.com
---
tools/perf/builtin-report.c |5 +
tools
de Melo a...@ghostprotocols.net
Cc: Arjan van de Ven ar...@linux.intel.com
Cc: Namhyung Kim namhy...@gmail.com
Cc: Yanmin Zhang yanmin.zh...@intel.com
Cc: Wu Fengguang fengguang...@intel.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Chenggang Qin
Commit-ID: 784f3390f9bd900adfb3b0373615e105a0d9749a
Gitweb: http://git.kernel.org/tip/784f3390f9bd900adfb3b0373615e105a0d9749a
Author: Chenggang Qin
AuthorDate: Fri, 11 Oct 2013 08:27:57 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 14 Oct 2013 12:21:23 -0300
perf symbols
Commit-ID: d4f74eb89199dc7bde5579783e9188841e1271e3
Gitweb: http://git.kernel.org/tip/d4f74eb89199dc7bde5579783e9188841e1271e3
Author: Chenggang Qin
AuthorDate: Fri, 11 Oct 2013 08:27:59 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 14 Oct 2013 12:21:20 -0300
perf symbols
Commit-ID: d4f74eb89199dc7bde5579783e9188841e1271e3
Gitweb: http://git.kernel.org/tip/d4f74eb89199dc7bde5579783e9188841e1271e3
Author: Chenggang Qin chenggang@taobao.com
AuthorDate: Fri, 11 Oct 2013 08:27:59 +0800
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Mon
Commit-ID: 784f3390f9bd900adfb3b0373615e105a0d9749a
Gitweb: http://git.kernel.org/tip/784f3390f9bd900adfb3b0373615e105a0d9749a
Author: Chenggang Qin chenggang@taobao.com
AuthorDate: Fri, 11 Oct 2013 08:27:57 +0800
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Mon
: Mike Galbraith
Cc: Andrew Morton
Signed-off-by: Chenggang Qin
Reviewed-by: Namhyung Kim
---
tools/perf/util/symbol-elf.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 4b12bf8..b4df870 100644
From: Chenggang Qin
In function symbols__fixup_duplicate(), while the duplicated symbols are found,
only the rb_node are deleted. The symbol structures themself are ignored.
Then, these memory areas are lost.
This patch fixed the bug.
Thanks.
Cc: David Ahern
Cc: Peter Zijlstra
Cc: Paul
From: Chenggang Qin
Some dsos' symsrc is neither syms_ss or runtime_ss. In this situation, the
corresponding ELF file is opened and mmapped in symsrc__init(), but they will
be not closed and munmapped in any place.
This bug can lead to mmap & munmap mismatched, the mmap areas will exist du
From: Chenggang Qin chenggang@taobao.com
Some dsos' symsrc is neither syms_ss or runtime_ss. In this situation, the
corresponding ELF file is opened and mmapped in symsrc__init(), but they will
be not closed and munmapped in any place.
This bug can lead to mmap munmap mismatched, the mmap
Carvalho de Melo a...@ghostprotocols.net
Cc: Arjan van de Ven ar...@linux.intel.com
Cc: Namhyung Kim namhy...@gmail.com
Cc: Yanmin Zhang yanmin.zh...@intel.com
Cc: Wu Fengguang fengguang...@intel.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Chenggang
From: Chenggang Qin chenggang@taobao.com
In function symbols__fixup_duplicate(), while the duplicated symbols are found,
only the rb_node are deleted. The symbol structures themself are ignored.
Then, these memory areas are lost.
This patch fixed the bug.
Thanks.
Cc: David Ahern dsah
From: Chenggang Qin
Vdso is only one in a system. It is not necessory to traverse the
macine->user_dsos list when looking for the dso of vdso.
The flag vdso_found should be replaced by a pointor that point to the dso of
vdso. If the pointer is NULL, dso of vdso have not been created. E
From: Chenggang Qin
If the list traversal is avoided by the last patch, the short name compare in
dsos__find() is unnecessary. The purpose of short name compare is only to find
the dso of vdso. If the vdso can be found by a pointor, the short name compare
can be removed.
Thanks
Cc: David Ahern
From: Chenggang Qin chenggang@taobao.com
If the list traversal is avoided by the last patch, the short name compare in
dsos__find() is unnecessary. The purpose of short name compare is only to find
the dso of vdso. If the vdso can be found by a pointor, the short name compare
can be removed
From: Chenggang Qin chenggang@taobao.com
Vdso is only one in a system. It is not necessory to traverse the
macine-user_dsos list when looking for the dso of vdso.
The flag vdso_found should be replaced by a pointor that point to the dso of
vdso. If the pointer is NULL, dso of vdso have
From: Chenggang Qin
Vdso is only one in a system. It is not necessory to traverse the
macine->user_dsos list while finding the dso of vdso.
The flag vdso_found should be replaced by a pointor that point to the dso of
vdso. If the pointer is NULL, dso of vdso have not been created. E
From: Chenggang Qin
If the list traversal is avoided by the last patch, the short name compare in
dsos__find() is unnecessary. The purpose of short name compare is only to find
the dso of vdso. If the vdso can be found by a pointor, the short name compare
can be removed.
Thanks
Cc: David Ahern
From: Chenggang Qin chenggang@taobao.com
Vdso is only one in a system. It is not necessory to traverse the
macine-user_dsos list while finding the dso of vdso.
The flag vdso_found should be replaced by a pointor that point to the dso of
vdso. If the pointer is NULL, dso of vdso have not been
From: Chenggang Qin chenggang@taobao.com
If the list traversal is avoided by the last patch, the short name compare in
dsos__find() is unnecessary. The purpose of short name compare is only to find
the dso of vdso. If the vdso can be found by a pointor, the short name compare
can be removed
From: Chenggang Qin
In function symbols__fixup_duplicate(), while the duplicated symbols are found,
only the rb_node are deleted. The symbol structures themself are ignored.
Then, these memory areas are lost.
This patch fixed the bug.
Thanks.
Cc: David Ahern
Cc: Peter Zijlstra
Cc: Paul
: Mike Galbraith
Cc: Andrew Morton
Signed-off-by: Chenggang Qin
---
tools/perf/util/symbol-elf.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 4b12bf8..b4df870 100644
--- a/tools/perf/util/symbol
From: Chenggang Qin
Some dsos' symsrc is neither syms_ss or runtime_ss. In this situation, the
corresponding ELF file is opened and mmapped in symsrc__init(), but they will
be not closed and munmapped in any place.
This bug can lead to mmap & munmap mismatched, the mmap areas will exist du
Carvalho de Melo a...@ghostprotocols.net
Cc: Arjan van de Ven ar...@linux.intel.com
Cc: Namhyung Kim namhy...@gmail.com
Cc: Yanmin Zhang yanmin.zh...@intel.com
Cc: Wu Fengguang fengguang...@intel.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Chenggang
From: Chenggang Qin chenggang@taobao.com
Some dsos' symsrc is neither syms_ss or runtime_ss. In this situation, the
corresponding ELF file is opened and mmapped in symsrc__init(), but they will
be not closed and munmapped in any place.
This bug can lead to mmap munmap mismatched, the mmap
From: Chenggang Qin chenggang@taobao.com
In function symbols__fixup_duplicate(), while the duplicated symbols are found,
only the rb_node are deleted. The symbol structures themself are ignored.
Then, these memory areas are lost.
This patch fixed the bug.
Thanks.
Cc: David Ahern dsah
From: Chenggang Qin
In function filename__read_debuglink(), after the elf_begin() mmapped the dso
file,
the execution stream may goto "out_close". So, the elf_end() is skipped, and the
munmap() cannot be executed.
While perf is executed for a long time, the files that are not
From: Chenggang Qin chenggang@taobao.com
In function filename__read_debuglink(), after the elf_begin() mmapped the dso
file,
the execution stream may goto out_close. So, the elf_end() is skipped, and the
munmap() cannot be executed.
While perf is executed for a long time, the files
Carvalho de Melo
Cc: Arjan van de Ven
Cc: Namhyung Kim
Cc: Yanmin Zhang
Cc: Wu Fengguang
Cc: Mike Galbraith
Cc: Andrew Morton
Signed-off-by: Chenggang Qin
---
tools/perf/util/trace-event-parse.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/perf/util/trace
From: chenggang@taobao.com
While I compile the perf in Red Hat Enterprise Linux Server release 5.4
(Tikanga),
I got a warning:
CC util/trace-event-parse.o
cc1: warnings being treated as errors
util/trace-event-parse.c: In function 'parse_proc_kallsyms':
util/trace-event-parse.c:232: warning
From: Chenggang Qin
If we execute "make clean" in perf's directory, many object files cannot be
cleaned in the current version.
For example:
While we run "make clean" in perf's directory, and run the command:
"fine ./ -name "*.o""
we will get:
From: Chenggang Qin
If we execute "make clean" in perf's directory, many object files cannot be
cleaned in the current version.
For example:
While we run "make clean" in perf's directory, and run the command:
"fine ./ -name "*.o""
we will get:
From: Chenggang Qin
If we execute "make clean" in perf's directory, many object files cannot be
cleaned in the current version.
For example:
While we run "make clean" in perf's directory, and run the command:
"fine ./ -name "*.o""
we will get:
From: Chenggang Qin chenggang@taobao.com
If we execute make clean in perf's directory, many object files cannot be
cleaned in the current version.
For example:
While we run make clean in perf's directory, and run the command:
fine ./ -name *.o
we will get
From: Chenggang Qin chenggang@taobao.com
If we execute make clean in perf's directory, many object files cannot be
cleaned in the current version.
For example:
While we run make clean in perf's directory, and run the command:
fine ./ -name *.o
we will get
From: Chenggang Qin chenggang@taobao.com
If we execute make clean in perf's directory, many object files cannot be
cleaned in the current version.
For example:
While we run make clean in perf's directory, and run the command:
fine ./ -name *.o
we will get
From: chenggang
While we run "make clean" in perf's directory, and run the command:
"fine ./ -name *.o"
we will get:
./arch/x86/util/unwind.o
./arch/x86/util/header.o
./arch/x86/util/dwarf-regs.o
./util/scripting-engines/trace-event-pytho
From: chenggang
This patch set base on the 3.8.rc7 kernel.
Here is the version 3, I optimized the performance and structure in this
version.
This patch set add a function that make the 'perf top -p $pid' is able to
perceive
the new threads that is forked by target processes. 'perf top{record
From: chenggang
The size of thread_map is fixed at initialized phase according to the
files in /proc/{$pid}. It cannot be expanded and shrinked while we want
to perceive the thread fork and exit events.
We transform the thread_map structure to a linked list, and implement some
interfaces
From: chenggang
The 2-dimensional array cannot expand and shrink easily while we want to
perceive the thread's fork and exit events on-the-fly.
We transform xyarray to a 2-demesional linked list. The x dimension is cpus and
is still a array. The y dimension is threads of interest
From: chenggang
Transformed evlist->mmap to xyarray. Then the evlist->mmap is transformed
to a linked list too.
1) perf_evlist__mmap_thread()
mmap a new fd for a new thread forked on-the-fly.
2) void perf_evlist__munmap_thread()
munmap a fd for a exited thread on-the-
From: chenggang
Transform evsel->id to xyarray, so it is transformed to a linked list
instead an array.
Cc: David Ahern
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Arjan van de Ven
Cc: Namhyung Kim
Cc: Yanmin Zhang
Cc: Wu Fengguang
Cc: M
From: chenggang
Add extend mechanism for evsel->id & evsel->fd.
Cc: David Ahern
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Arjan van de Ven
Cc: Namhyung Kim
Cc: Yanmin Zhang
Cc: Wu Fengguang
Cc: Mike Galbraith
Cc: Andrew Morton
From: chenggang
Add extend mechanism for mmap & pollfd. Then we can adjust them while threads
are forked or exited.
Cc: David Ahern
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Arjan van de Ven
Cc: Namhyung Kim
Cc: Yanmin Zhang
Cc: Wu Fengg
From: chenggang
Changed the method to traverse the evlist->mmap list. The evlist->mmap
list is traversed very frequently. So we need to be more efficient to do
it.
Cc: David Ahern
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Arjan van de V
From: chenggang
Many applications will fork threads on-the-fly, these threads could exit before
the main thread exit. The perf top tool should perceive the new forked threads
while we profile a special application.
If the target process fork a thread or a thread exit, we will get
From: chenggang chenggang@taobao.com
While we run make clean in perf's directory, and run the command:
fine ./ -name *.o
we will get:
./arch/x86/util/unwind.o
./arch/x86/util/header.o
./arch/x86/util/dwarf-regs.o
./util/scripting-engines/trace-event
From: chenggang chenggang@taobao.com
Many applications will fork threads on-the-fly, these threads could exit before
the main thread exit. The perf top tool should perceive the new forked threads
while we profile a special application.
If the target process fork a thread or a thread exit, we
From: chenggang chenggang@taobao.com
Changed the method to traverse the evlist-mmap list. The evlist-mmap
list is traversed very frequently. So we need to be more efficient to do
it.
Cc: David Ahern dsah...@gmail.com
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Paul Mackerras pau
From: chenggang chenggang@taobao.com
Add extend mechanism for mmap pollfd. Then we can adjust them while threads
are forked or exited.
Cc: David Ahern dsah...@gmail.com
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Paul Mackerras pau...@samba.org
Cc: Ingo Molnar mi...@redhat.com
Cc: Arnaldo
From: chenggang chenggang@taobao.com
Add extend mechanism for evsel-id evsel-fd.
Cc: David Ahern dsah...@gmail.com
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Paul Mackerras pau...@samba.org
Cc: Ingo Molnar mi...@redhat.com
Cc: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Cc: Arjan
From: chenggang chenggang@taobao.com
Transform evsel-id to xyarray, so it is transformed to a linked list
instead an array.
Cc: David Ahern dsah...@gmail.com
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Paul Mackerras pau...@samba.org
Cc: Ingo Molnar mi...@redhat.com
Cc: Arnaldo Carvalho de
From: chenggang chenggang@taobao.com
Transformed evlist-mmap to xyarray. Then the evlist-mmap is transformed
to a linked list too.
1) perf_evlist__mmap_thread()
mmap a new fd for a new thread forked on-the-fly.
2) void perf_evlist__munmap_thread()
munmap a fd for a exited thread
From: chenggang chenggang@taobao.com
The 2-dimensional array cannot expand and shrink easily while we want to
perceive the thread's fork and exit events on-the-fly.
We transform xyarray to a 2-demesional linked list. The x dimension is cpus and
is still a array. The y dimension is threads
From: chenggang chenggang@taobao.com
The size of thread_map is fixed at initialized phase according to the
files in /proc/{$pid}. It cannot be expanded and shrinked while we want
to perceive the thread fork and exit events.
We transform the thread_map structure to a linked list, and implement
From: chenggang chenggang@taobao.com
This patch set base on the 3.8.rc7 kernel.
Here is the version 3, I optimized the performance and structure in this
version.
This patch set add a function that make the 'perf top -p $pid' is able to
perceive
the new threads that is forked by target
From: chenggang@taobao.com
This patch set add a function that make the 'perf top -p $pid' is able to
perceive
the new threads that is forked by target processes. 'perf top{record} -p $pid'
can
perceive the threads are forked before we execute perf, but it cannot perceive
the
new threads
From: chenggang
The 2-dimensional array cannot expand and shrink easily while we want to
response the thread's fork and exit events on-the-fly.
We transform xyarray to a 2-demesional linked list. The row is still a array,
but column is implemented as a list. The number of nodes in every row
From: chenggang
The size of thread_map is fixed at initialized phase according to the
files in /proc/{$pid}. It cannot be expanded and shrinked easily while we
want to response the thread fork and exit events.
We transform the thread_map structure to a linked list, and implement some
interfaces
From: chenggang
evlist->mmap, evsel->id, evsel->sample_id are arrays. They cannot be expended or
shrinked easily for the forked and exited threads while we get the fork and exit
events.
We transfromed them to linked list with the new xyarray.
xyarray is a 2-dimensional structure
From: chenggang
Many applications will fork threads on-the-fly, these threads could exit before
the main thread exit. The perf top tool should perceive the new forked threads
while we profile a special application.
If the target process fork a thread or a thread exit, we will get
From: chenggang
Many applications will fork threads on-the-fly, these threads could exit before
the main thread exit. The perf top tool should perceive the new forked threads
while we profile a special application.
If the target process fork a thread or a thread exit, we will get
From: chenggang
The size of thread_map is fixed at initialized phase according to the
files in /proc/{$pid}. It cannot be expanded and shrinked easily while we
want to response the thread fork and exit events.
We transform the thread_map structure to a linked list, and implement some
interfaces
From: chenggang
evlist->mmap, evsel->id, evsel->sample_id are arrays. They cannot be expended or
shrinked easily for the forked and exited threads while we get the fork and exit
events.
We transfromed them to linked list with the new xyarray.
xyarray is a 2-dimensional structure
From: chenggang
The 2-dimensional array cannot expand and shrink easily while we want to
response the thread's fork and exit events on-the-fly.
We transform xyarray to a 2-demesional linked list. The row is still a array,
but column is implemented as a list. The number of nodes in every row
From: chenggang@taobao.com
This patch set add a function that make the 'perf top -p $pid' is able to
perceive
the new threads that is forked by target processes. 'perf top{record} -p $pid'
can
perceive the threads are forked before we execute perf, but it cannot perceive
the
new threads
From: chenggang@taobao.com
This patch set add a function that make the 'perf top -p $pid' is able to
perceive
the new threads that is forked by target processes. 'perf top{record} -p $pid'
can
perceive the threads are forked before we execute perf, but it cannot perceive
the
new threads
From: chenggang chenggang@taobao.com
The 2-dimensional array cannot expand and shrink easily while we want to
response the thread's fork and exit events on-the-fly.
We transform xyarray to a 2-demesional linked list. The row is still a array,
but column is implemented as a list. The number
From: chenggang chenggang@taobao.com
The size of thread_map is fixed at initialized phase according to the
files in /proc/{$pid}. It cannot be expanded and shrinked easily while we
want to response the thread fork and exit events.
We transform the thread_map structure to a linked list
From: chenggang chenggang@taobao.com
evlist-mmap, evsel-id, evsel-sample_id are arrays. They cannot be expended or
shrinked easily for the forked and exited threads while we get the fork and exit
events.
We transfromed them to linked list with the new xyarray.
xyarray is a 2-dimensional
From: chenggang chenggang@taobao.com
Many applications will fork threads on-the-fly, these threads could exit before
the main thread exit. The perf top tool should perceive the new forked threads
while we profile a special application.
If the target process fork a thread or a thread exit, we
From: chenggang chenggang@taobao.com
Many applications will fork threads on-the-fly, these threads could exit before
the main thread exit. The perf top tool should perceive the new forked threads
while we profile a special application.
If the target process fork a thread or a thread exit, we
From: chenggang chenggang@taobao.com
evlist-mmap, evsel-id, evsel-sample_id are arrays. They cannot be expended or
shrinked easily for the forked and exited threads while we get the fork and exit
events.
We transfromed them to linked list with the new xyarray.
xyarray is a 2-dimensional
From: chenggang chenggang@taobao.com
The size of thread_map is fixed at initialized phase according to the
files in /proc/{$pid}. It cannot be expanded and shrinked easily while we
want to response the thread fork and exit events.
We transform the thread_map structure to a linked list
From: chenggang chenggang@taobao.com
The 2-dimensional array cannot expand and shrink easily while we want to
response the thread's fork and exit events on-the-fly.
We transform xyarray to a 2-demesional linked list. The row is still a array,
but column is implemented as a list. The number
From: chenggang@taobao.com
This patch set add a function that make the 'perf top -p $pid' is able to
perceive
the new threads that is forked by target processes. 'perf top{record} -p $pid'
can
perceive the threads are forked before we execute perf, but it cannot perceive
the
new threads
From: chenggang@taobao.com
The last version of this patch need to introduce 2 new tracepoint events in VFS,
but introduce new tracepoint events into VFS is not a clever idea. So, I
modified
this patch, and only use a existing tracepoint event (ext4:ext4_direct_IO_exit).
If the engineers
From: chenggang@taobao.com
The last version of this patch need to introduce 2 new tracepoint events in VFS,
but introduce new tracepoint events into VFS is not a clever idea. So, I
modified
this patch, and only use a existing tracepoint event (ext4:ext4_direct_IO_exit).
If the engineers
From: chenggang@taobao.com
The last version of this patch need to introduce 2 new tracepoint events in VFS,
but introduce new tracepoint events into VFS is not a clever idea. So, I
modified
this patch, and only use a existing tracepoint event (ext4:ext4_direct_IO_exit).
If the engineers
From: chenggang@taobao.com
The last version of this patch need to introduce 2 new tracepoint events in VFS,
but introduce new tracepoint events into VFS is not a clever idea. So, I
modified
this patch, and only use a existing tracepoint event (ext4:ext4_direct_IO_exit).
If the engineers
From: chenggang
Yesterday, I implemented these tracepoint events in VFS subsystem.
It is not a good idea.
Now, I modified two existing tracepoint events in ext4 subsystem to implement
the same function.
Many database systems use their own page cache subsystems and use the direct IO
to access
From: chenggang chenggang@alibaba-inc.com
Yesterday, I implemented these tracepoint events in VFS subsystem.
It is not a good idea.
Now, I modified two existing tracepoint events in ext4 subsystem to implement
the same function.
Many database systems use their own page cache subsystems
From: chenggang@gmail.com
This patch depends on a prev patch: https://lkml.org/lkml/2013/1/29/47
If the engineers want to analyze the direct io behavior of some applications
without source code, perf tools with some appropriate tracepoints events in the
VFS subsystem are excellent choice
From: chenggang@gmail.com
This patch depends on a prev patch: https://lkml.org/lkml/2013/1/29/47
If the engineers want to analyze the direct io behavior of some applications
without source code, perf tools with some appropriate tracepoints events in the
VFS subsystem are excellent choice
From: chenggang@gmail.com
This version changed some type definition according to Steven's advise.
Thanks for Steven.
If the engineers want to analyze the file access behavior of some applications
without source code, perf tools with some appropriate tracepoints events in the
VFS subsystem
From: chenggang@gmail.com
This patch depends on a prev patch: https://lkml.org/lkml/2013/1/29/47
If the engineers want to analyze the direct io behavior of some applications
without source code, perf tools with some appropriate tracepoints events in the
VFS subsystem are excellent choice
From: chenggang@gmail.com
This patch depends on the other patch: https://lkml.org/lkml/2013/1/29/47
Because this patch uses 2 tracepoint events are introduced by the patch of the
above mentioned.
If the engineers want to analyze the file access behavior of some applications
without source
From: chenggang@gmail.com
This patch depends on the other patch: https://lkml.org/lkml/2013/1/29/47
Because this patch uses 2 tracepoint events are introduced by the patch of the
above mentioned.
If the engineers want to analyze the file access behavior of some applications
without source
From: chenggang@gmail.com
This patch depends on a prev patch: https://lkml.org/lkml/2013/1/29/47
If the engineers want to analyze the direct io behavior of some applications
without source code, perf tools with some appropriate tracepoints events in the
VFS subsystem are excellent choice
From: chenggang@gmail.com
This version changed some type definition according to Steven's advise.
Thanks for Steven.
If the engineers want to analyze the file access behavior of some applications
without source code, perf tools with some appropriate tracepoints events in the
VFS subsystem
1 - 100 of 118 matches
Mail list logo
