Re: [f2fs-dev] [RFC] f2fs: fix a race condition between evict & gc

[Hou Pengyang]

On 2016/5/18 1:23, Jaegeuk Kim wrote:

On Tue, May 17, 2016 at 11:00:53AM +0800, Hou Pengyang wrote:

On 2016/5/16 23:10, Chao Yu wrote:
Hi chao,

Hi Pengyang,

On 2016/5/16 18:40, Hou Pengyang wrote:

When collecting data segment(gc_data_segment), there is a race condition
between evict and phases of gc:
0) ra_node_page(dnode)
1) ra_node_page(inode)
<--- evict the inode
2) f2fs_iget get the inode and add it to gc_list
3) move_data_page

In step 2), f2fs_iget does NOT find the inode and allocs a new inode as result,


If inode was unlinked and then be evicted, f2fs_iget should fail when reading
inode's page as blkaddr of this node is null.

agree, after do_read_inode fail, the newly created inode would be
freed as a bad inode and f2fs_iget fails. But this may lead to create
file fail:
gc:iget_locked
 < touch/mkdir(reuse the evicted ino)
gc:free the bad inode


Seems there is no problem.

After f2fs_evict_inode(ino),

f2fs_iget(ino)
  - iget_failed()  f2fs_create()
- f2fs_new_inode()
- ino = alloc_nid()
- insert_inode_locked()
 *** spin_lock(_hash_lock)
 - spin_lock(>i_lock)
 - __iget(old)
   - make_bad_inode()- spin_unlock(>i_lock)
- remove_inode_hash()- spin_unlock(_hash_lock)
 - spin_lock(_hash_lock)   - wait_on_inode(old)


oh.. wait_on_inode. OK, Kim, get it, thanks for your answer.


 - spin_lock(>i_lock)
 - list_del
 - spin_unlock(>i_lock)
 - spin_unlock(_hash_lock)
- unlock_new_inode()
 - wake_up_bit(>i_state, __I_NEW) --> wake up!
 - iput(old) whish was unhashed.
 - goto to ***
- iput()


during the bad inode allocated and freed in gc, the inode is reserved
in the global inode_hash, while the ino is a free nid in free_nid tree.

touch/mkdir may reuse the ino, during the touch/mkdir path, the global
inode_hash would be checked if the ino file exists. Under this
scenario, because of the gc bad inode in inode_hash, touch/mkdir would
fail.

ilookup seems better, as no need to alloc and free a bad inode.

if ilookup fails, that exactly means inode has been evicted and no need
to gc;


No, we should do gc for data blocks owned by *evicted* inodes as well.

Thanks,


if ilookup success, before phase 3, is_alive to deal with the ino reuse
scenario;

Do I miss anything else?
thanks

If inode still have non-zero nlink value and then be evicted, we should allow gc
thread to reference this inode for moving its data pages.

Thanks,


which is not resonable.

This patch changes f2fs_iget to ilookup. when no inode is found, no new inode is
created.

Signed-off-by: Hou Pengyang <houpengy...@huawei.com>
---
   fs/f2fs/gc.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 38d56f6..6e73193 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -717,8 +717,8 @@ next_step:
ofs_in_node = le16_to_cpu(entry->ofs_in_node);

if (phase == 2) {
-   inode = f2fs_iget(sb, dni.ino);
-   if (IS_ERR(inode) || is_bad_inode(inode))
+   inode = ilookup(sb, dni.ino);
+   if (!inode || IS_ERR(inode) || is_bad_inode(inode))
continue;

/* if encrypted inode, let's go phase 3 */



.





--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Linux-f2fs-devel mailing list
linux-f2fs-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel


.

Re: [f2fs-dev] [RFC] f2fs: fix a race condition between evict & gc

[Hou Pengyang]

On 2016/5/18 1:23, Jaegeuk Kim wrote:

On Tue, May 17, 2016 at 11:00:53AM +0800, Hou Pengyang wrote:

On 2016/5/16 23:10, Chao Yu wrote:
Hi chao,

Hi Pengyang,

On 2016/5/16 18:40, Hou Pengyang wrote:

When collecting data segment(gc_data_segment), there is a race condition
between evict and phases of gc:
0) ra_node_page(dnode)
1) ra_node_page(inode)
<--- evict the inode
2) f2fs_iget get the inode and add it to gc_list
3) move_data_page

In step 2), f2fs_iget does NOT find the inode and allocs a new inode as result,


If inode was unlinked and then be evicted, f2fs_iget should fail when reading
inode's page as blkaddr of this node is null.

agree, after do_read_inode fail, the newly created inode would be
freed as a bad inode and f2fs_iget fails. But this may lead to create
file fail:
gc:iget_locked
 < touch/mkdir(reuse the evicted ino)
gc:free the bad inode


Seems there is no problem.

After f2fs_evict_inode(ino),

f2fs_iget(ino)
  - iget_failed()  f2fs_create()
- f2fs_new_inode()
- ino = alloc_nid()
- insert_inode_locked()
 *** spin_lock(_hash_lock)
 - spin_lock(>i_lock)
 - __iget(old)
   - make_bad_inode()- spin_unlock(>i_lock)
- remove_inode_hash()- spin_unlock(_hash_lock)
 - spin_lock(_hash_lock)   - wait_on_inode(old)


oh.. wait_on_inode. OK, Kim, get it, thanks for your answer.


 - spin_lock(>i_lock)
 - list_del
 - spin_unlock(>i_lock)
 - spin_unlock(_hash_lock)
- unlock_new_inode()
 - wake_up_bit(>i_state, __I_NEW) --> wake up!
 - iput(old) whish was unhashed.
 - goto to ***
- iput()


during the bad inode allocated and freed in gc, the inode is reserved
in the global inode_hash, while the ino is a free nid in free_nid tree.

touch/mkdir may reuse the ino, during the touch/mkdir path, the global
inode_hash would be checked if the ino file exists. Under this
scenario, because of the gc bad inode in inode_hash, touch/mkdir would
fail.

ilookup seems better, as no need to alloc and free a bad inode.

if ilookup fails, that exactly means inode has been evicted and no need
to gc;


No, we should do gc for data blocks owned by *evicted* inodes as well.

Thanks,


if ilookup success, before phase 3, is_alive to deal with the ino reuse
scenario;

Do I miss anything else?
thanks

If inode still have non-zero nlink value and then be evicted, we should allow gc
thread to reference this inode for moving its data pages.

Thanks,


which is not resonable.

This patch changes f2fs_iget to ilookup. when no inode is found, no new inode is
created.

Signed-off-by: Hou Pengyang 
---
   fs/f2fs/gc.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 38d56f6..6e73193 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -717,8 +717,8 @@ next_step:
ofs_in_node = le16_to_cpu(entry->ofs_in_node);

if (phase == 2) {
-   inode = f2fs_iget(sb, dni.ino);
-   if (IS_ERR(inode) || is_bad_inode(inode))
+   inode = ilookup(sb, dni.ino);
+   if (!inode || IS_ERR(inode) || is_bad_inode(inode))
continue;

/* if encrypted inode, let's go phase 3 */



.





--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Linux-f2fs-devel mailing list
linux-f2fs-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel


.

Re: [f2fs-dev] [RFC] f2fs: fix a race condition between evict & gc

[Hou Pengyang]

On 2016/5/16 23:10, Chao Yu wrote:
Hi chao,

Hi Pengyang,

On 2016/5/16 18:40, Hou Pengyang wrote:

When collecting data segment(gc_data_segment), there is a race condition
between evict and phases of gc:
0) ra_node_page(dnode)
1) ra_node_page(inode)
<--- evict the inode
2) f2fs_iget get the inode and add it to gc_list
3) move_data_page

In step 2), f2fs_iget does NOT find the inode and allocs a new inode as result,


If inode was unlinked and then be evicted, f2fs_iget should fail when reading
inode's page as blkaddr of this node is null.

agree, after do_read_inode fail, the newly created inode would be
freed as a bad inode and f2fs_iget fails. But this may lead to create
file fail:
gc:iget_locked
   < touch/mkdir(reuse the evicted ino)
gc:free the bad inode

during the bad inode allocated and freed in gc, the inode is reserved
in the global inode_hash, while the ino is a free nid in free_nid tree.

touch/mkdir may reuse the ino, during the touch/mkdir path, the global
inode_hash would be checked if the ino file exists. Under this
scenario, because of the gc bad inode in inode_hash, touch/mkdir would
fail.

ilookup seems better, as no need to alloc and free a bad inode.

if ilookup fails, that exactly means inode has been evicted and no need
to gc;
if ilookup success, before phase 3, is_alive to deal with the ino reuse
scenario;

Do I miss anything else?
thanks

If inode still have non-zero nlink value and then be evicted, we should allow gc
thread to reference this inode for moving its data pages.

Thanks,


which is not resonable.

This patch changes f2fs_iget to ilookup. when no inode is found, no new inode is
created.

Signed-off-by: Hou Pengyang <houpengy...@huawei.com>
---
  fs/f2fs/gc.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 38d56f6..6e73193 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -717,8 +717,8 @@ next_step:
ofs_in_node = le16_to_cpu(entry->ofs_in_node);

if (phase == 2) {
-   inode = f2fs_iget(sb, dni.ino);
-   if (IS_ERR(inode) || is_bad_inode(inode))
+   inode = ilookup(sb, dni.ino);
+   if (!inode || IS_ERR(inode) || is_bad_inode(inode))
continue;

/* if encrypted inode, let's go phase 3 */



.

Re: [f2fs-dev] [RFC] f2fs: fix a race condition between evict & gc

[Hou Pengyang]

On 2016/5/16 23:10, Chao Yu wrote:
Hi chao,

Hi Pengyang,

On 2016/5/16 18:40, Hou Pengyang wrote:

When collecting data segment(gc_data_segment), there is a race condition
between evict and phases of gc:
0) ra_node_page(dnode)
1) ra_node_page(inode)
<--- evict the inode
2) f2fs_iget get the inode and add it to gc_list
3) move_data_page

In step 2), f2fs_iget does NOT find the inode and allocs a new inode as result,


If inode was unlinked and then be evicted, f2fs_iget should fail when reading
inode's page as blkaddr of this node is null.

agree, after do_read_inode fail, the newly created inode would be
freed as a bad inode and f2fs_iget fails. But this may lead to create
file fail:
gc:iget_locked
   < touch/mkdir(reuse the evicted ino)
gc:free the bad inode

during the bad inode allocated and freed in gc, the inode is reserved
in the global inode_hash, while the ino is a free nid in free_nid tree.

touch/mkdir may reuse the ino, during the touch/mkdir path, the global
inode_hash would be checked if the ino file exists. Under this
scenario, because of the gc bad inode in inode_hash, touch/mkdir would
fail.

ilookup seems better, as no need to alloc and free a bad inode.

if ilookup fails, that exactly means inode has been evicted and no need
to gc;
if ilookup success, before phase 3, is_alive to deal with the ino reuse
scenario;

Do I miss anything else?
thanks

If inode still have non-zero nlink value and then be evicted, we should allow gc
thread to reference this inode for moving its data pages.

Thanks,


which is not resonable.

This patch changes f2fs_iget to ilookup. when no inode is found, no new inode is
created.

Signed-off-by: Hou Pengyang 
---
  fs/f2fs/gc.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 38d56f6..6e73193 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -717,8 +717,8 @@ next_step:
ofs_in_node = le16_to_cpu(entry->ofs_in_node);

if (phase == 2) {
-   inode = f2fs_iget(sb, dni.ino);
-   if (IS_ERR(inode) || is_bad_inode(inode))
+   inode = ilookup(sb, dni.ino);
+   if (!inode || IS_ERR(inode) || is_bad_inode(inode))
continue;

/* if encrypted inode, let's go phase 3 */



.

[RFC] f2fs: fix a race condition between evict & gc

[Hou Pengyang]

When collecting data segment(gc_data_segment), there is a race condition
between evict and phases of gc:
0) ra_node_page(dnode)
1) ra_node_page(inode)
<--- evict the inode
2) f2fs_iget get the inode and add it to gc_list 
3) move_data_page

In step 2), f2fs_iget does NOT find the inode and allocs a new inode as result,
which is not resonable.

This patch changes f2fs_iget to ilookup. when no inode is found, no new inode is
created.

Signed-off-by: Hou Pengyang <houpengy...@huawei.com>
---
 fs/f2fs/gc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 38d56f6..6e73193 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -717,8 +717,8 @@ next_step:
ofs_in_node = le16_to_cpu(entry->ofs_in_node);
 
if (phase == 2) {
-   inode = f2fs_iget(sb, dni.ino);
-   if (IS_ERR(inode) || is_bad_inode(inode))
+   inode = ilookup(sb, dni.ino);
+   if (!inode || IS_ERR(inode) || is_bad_inode(inode))
continue;
 
/* if encrypted inode, let's go phase 3 */
-- 
1.9.1

[RFC] f2fs: fix a race condition between evict & gc

[Hou Pengyang]

When collecting data segment(gc_data_segment), there is a race condition
between evict and phases of gc:
0) ra_node_page(dnode)
1) ra_node_page(inode)
<--- evict the inode
2) f2fs_iget get the inode and add it to gc_list 
3) move_data_page

In step 2), f2fs_iget does NOT find the inode and allocs a new inode as result,
which is not resonable.

This patch changes f2fs_iget to ilookup. when no inode is found, no new inode is
created.

Signed-off-by: Hou Pengyang 
---
 fs/f2fs/gc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 38d56f6..6e73193 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -717,8 +717,8 @@ next_step:
ofs_in_node = le16_to_cpu(entry->ofs_in_node);
 
if (phase == 2) {
-   inode = f2fs_iget(sb, dni.ino);
-   if (IS_ERR(inode) || is_bad_inode(inode))
+   inode = ilookup(sb, dni.ino);
+   if (!inode || IS_ERR(inode) || is_bad_inode(inode))
continue;
 
/* if encrypted inode, let's go phase 3 */
-- 
1.9.1

Re: [f2fs-dev] [PATCH 11/11] f2fs: retry to truncate blocks in -ENOMEM case

[Hou Pengyang]

On 2016/5/4 2:21, Jaegeuk Kim wrote:

This patch modifies to retry truncating node blocks in -ENOMEM case.


Hi, Kim. in this patch, I think there is NO chance to retry for -ENOMEM.

This is because if exist_written_data returns false, we can confirm that
this inode has been released from orphan radix-tree:
f2fs_evict_inode
 ---> remove_inode_page
---> truncate_node
---> remove_orphan_inode
On this condition, err is 0, So it won't enter:
if (err && err != -ENOENT)
{
...
}
sequentially, there is no chance to truncate node blocks again.
I miss something else?

How about this patch?

--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -345,6 +345,7 @@ void f2fs_evict_inode(struct inode *inode)
set_inode_flag(fi, FI_NO_ALLOC);
i_size_write(inode, 0);

+retry:
if (F2FS_HAS_BLOCKS(inode))
err = f2fs_truncate(inode, true);

@@ -354,6 +355,11 @@ void f2fs_evict_inode(struct inode *inode)
f2fs_unlock_op(sbi);
}

+   if (err == -ENOMEM) {
+   err = 0;
+   goto retry;
+   }
+
sb_end_intwrite(inode->i_sb);
 no_delete:
stat_dec_inline_xattr(inode);

Signed-off-by: Jaegeuk Kim 
---
  fs/f2fs/inode.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index f4ac851..5cccd7a 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -344,7 +344,7 @@ void f2fs_evict_inode(struct inode *inode)
sb_start_intwrite(inode->i_sb);
set_inode_flag(fi, FI_NO_ALLOC);
i_size_write(inode, 0);
-
+retry:
if (F2FS_HAS_BLOCKS(inode))
err = f2fs_truncate(inode, true);

@@ -374,6 +374,11 @@ no_delete:

if (err && err != -ENOENT) {
if (!exist_written_data(sbi, inode->i_ino, ORPHAN_INO)) {
+   /* give more chances, if ENOMEM case */
+   if (err == -ENOMEM) {
+   err = 0;
+   goto retry;
+   }
/*
 * get here because we failed to release resource
 * of inode previously, reminder our user to run fsck

Re: [f2fs-dev] [PATCH 11/11] f2fs: retry to truncate blocks in -ENOMEM case

[Hou Pengyang]

On 2016/5/4 2:21, Jaegeuk Kim wrote:

This patch modifies to retry truncating node blocks in -ENOMEM case.


Hi, Kim. in this patch, I think there is NO chance to retry for -ENOMEM.

This is because if exist_written_data returns false, we can confirm that
this inode has been released from orphan radix-tree:
f2fs_evict_inode
 ---> remove_inode_page
---> truncate_node
---> remove_orphan_inode
On this condition, err is 0, So it won't enter:
if (err && err != -ENOENT)
{
...
}
sequentially, there is no chance to truncate node blocks again.
I miss something else?

How about this patch?

--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -345,6 +345,7 @@ void f2fs_evict_inode(struct inode *inode)
set_inode_flag(fi, FI_NO_ALLOC);
i_size_write(inode, 0);

+retry:
if (F2FS_HAS_BLOCKS(inode))
err = f2fs_truncate(inode, true);

@@ -354,6 +355,11 @@ void f2fs_evict_inode(struct inode *inode)
f2fs_unlock_op(sbi);
}

+   if (err == -ENOMEM) {
+   err = 0;
+   goto retry;
+   }
+
sb_end_intwrite(inode->i_sb);
 no_delete:
stat_dec_inline_xattr(inode);

Signed-off-by: Jaegeuk Kim 
---
  fs/f2fs/inode.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index f4ac851..5cccd7a 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -344,7 +344,7 @@ void f2fs_evict_inode(struct inode *inode)
sb_start_intwrite(inode->i_sb);
set_inode_flag(fi, FI_NO_ALLOC);
i_size_write(inode, 0);
-
+retry:
if (F2FS_HAS_BLOCKS(inode))
err = f2fs_truncate(inode, true);

@@ -374,6 +374,11 @@ no_delete:

if (err && err != -ENOENT) {
if (!exist_written_data(sbi, inode->i_ino, ORPHAN_INO)) {
+   /* give more chances, if ENOMEM case */
+   if (err == -ENOMEM) {
+   err = 0;
+   goto retry;
+   }
/*
 * get here because we failed to release resource
 * of inode previously, reminder our user to run fsck

Re: [RFC] perf tools: Add hugetlbfs memory recognition

[Hou Pengyang]

On 2015/6/30 22:50, Arnaldo Carvalho de Melo wrote:

Em Tue, Jun 30, 2015 at 05:33:05PM +0800, Hou Pengyang escreveu:

On 2015/6/29 21:42, Arnaldo Carvalho de Melo wrote:

Em Mon, Jun 29, 2015 at 10:23:29AM -0300, Arnaldo Carvalho de Melo escreveu:

Em Sat, Jun 27, 2015 at 05:08:20PM +0800, Hou Pengyang escreveu:

So I wonder if there is a need to read /proc/pid/smaps instead of
/proc/pid/maps to generate MMAP2 event. Or we should solve the problem by
another way?


Doing some research now...


Bummer, seems that only smaps -> ... -> show_smap_vma_flags() will
expose that to userspace...

Perhaps we can look at some global stat for HugeTLB fs to figure out if
we really, really need to parse smaps instead of just maps? I.e. in my
system, a desktop one, F21, I have:



It seems no other info tell us if one process is using hugetlbfs.
So how about an option to tell perf explicitly which file is from
hugetlbfs, like:

./perf report --hugetlb-file=/mnt/huge/hugepagefile

So that, we can check if a mmap area is from hugetlbfs by its name
instead of MAP_HUGETLB.


Well, we _can_ detect this automatically, its just a matter of parsing
/proc/PID/smaps, right?

What I was discussing was a way only parse smaps when we know we need
to, i.e. when we, for instance, parsing /proc/PID/maps, find a map that
we think may be a hugetlb one, maybe some other way to tell us that
hugetlb maps are in place, looking at the hugetlbfs stats somehow?



Another solution, we can parse /proc/self/mounts. Here is the
/proc/self/mounts in my system:

.
/dev/root / ext2 rw,relatime,errors=remount-ro 0 0
tracefs /sys/kernel/debug/tracing tracefs rw,relatime 0 0
nodev /mnt/huge hugetlbfs rw,relatime 0 0


from /proc/self/mounts, we can get mount point of hugetlbfs.
in my system, it is "/mnt/huge". So that, when mmap2 event
comes from userspace, we can compare prefix of filename with
hugetlbfs mount point (e.g "/mnt/huge") to check if it is a
file in hugetlbfs. if it is, set MAP_HUGELTB, otherwise, not set.

There is no need to parse /proc/PID/smaps now, what's more,
it is not difficult to parse "/proc/self/mounts".


- Arnaldo

.




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

Re: [RFC] perf tools: Add hugetlbfs memory recognition

[Hou Pengyang]

On 2015/6/30 22:50, Arnaldo Carvalho de Melo wrote:

Em Tue, Jun 30, 2015 at 05:33:05PM +0800, Hou Pengyang escreveu:

On 2015/6/29 21:42, Arnaldo Carvalho de Melo wrote:

Em Mon, Jun 29, 2015 at 10:23:29AM -0300, Arnaldo Carvalho de Melo escreveu:

Em Sat, Jun 27, 2015 at 05:08:20PM +0800, Hou Pengyang escreveu:

So I wonder if there is a need to read /proc/pid/smaps instead of
/proc/pid/maps to generate MMAP2 event. Or we should solve the problem by
another way?


Doing some research now...


Bummer, seems that only smaps - ... - show_smap_vma_flags() will
expose that to userspace...

Perhaps we can look at some global stat for HugeTLB fs to figure out if
we really, really need to parse smaps instead of just maps? I.e. in my
system, a desktop one, F21, I have:



It seems no other info tell us if one process is using hugetlbfs.
So how about an option to tell perf explicitly which file is from
hugetlbfs, like:

./perf report --hugetlb-file=/mnt/huge/hugepagefile

So that, we can check if a mmap area is from hugetlbfs by its name
instead of MAP_HUGETLB.


Well, we _can_ detect this automatically, its just a matter of parsing
/proc/PID/smaps, right?

What I was discussing was a way only parse smaps when we know we need
to, i.e. when we, for instance, parsing /proc/PID/maps, find a map that
we think may be a hugetlb one, maybe some other way to tell us that
hugetlb maps are in place, looking at the hugetlbfs stats somehow?



Another solution, we can parse /proc/self/mounts. Here is the
/proc/self/mounts in my system:

.
/dev/root / ext2 rw,relatime,errors=remount-ro 0 0
tracefs /sys/kernel/debug/tracing tracefs rw,relatime 0 0
nodev /mnt/huge hugetlbfs rw,relatime 0 0


from /proc/self/mounts, we can get mount point of hugetlbfs.
in my system, it is /mnt/huge. So that, when mmap2 event
comes from userspace, we can compare prefix of filename with
hugetlbfs mount point (e.g /mnt/huge) to check if it is a
file in hugetlbfs. if it is, set MAP_HUGELTB, otherwise, not set.

There is no need to parse /proc/PID/smaps now, what's more,
it is not difficult to parse /proc/self/mounts.


- Arnaldo

.




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

[PATCH v2] perf tools: Add hugetlbfs memory recognition

[Hou Pengyang]

Maps for JIT is helpful for symbols-parsing for anon-executable-memory.
What we need to do is to add (START, SIZE, symbolname) to /tmp/perf-%d.map
(%d = pid of process), and perf would parse symbol located in this area
according to /tmp/perf-%d.map. It works well for normal mmap.

However, when we alloc such memory from hugetlbfs by the following code:

..

fd = open("/mnt/huge/hugepagefile", O_CREAT | O_RDWR, 0755);
if (fd < 0) {
perror("Open failed");
exit(1);
}   
addr = mmap(ADDR, LENGTH, PROT_READ | PROT_WRITE | \   
PROT_EXEC, MAP_SHARED, fd, 0); 

..
where hugetlbfs is mounted in /mnt/huge. Symbols could not be parsed correctly:

#perf report
   86.96% 0.00%  hugepage-mmap  hugepagefile  [.] 0xffe0005c
  
   86.96% 0.00%  hugepage-mmap  hugepagefile  [.] 0xffe000ac

This is because such mmap area's file backed is "/mnt/huge/hugepagefile", a 
node 
in pseudo filesystem, it is useless for symbol-parsing. so wo had better 
recognize 
such hugetlbfs area, and rename it's filename to /tmp/perf-%d.map, just as 
anon-memory
and no_dso_memory do. 

This patch imports a new option named --hugetlb-file to let user tell perf
explicitly which file is in hugetlbfs, and mmap area whose backed filenode is 
in 
hugetlbfs would be recognized as memory without dso in function 
is_no_dso_memory. 

After this patch:
#perf report 
   86.96% 0.00%  hugepage-mmap  perf-182.map[.] 0x0020005c 
   86.96% 0.00%  hugepage-mmap  perf-182.map[.] 0x002000ac

We can add maps info to perf-182.map for further symbols-parsing.

Signed-off-by: Hou Pengyang 
---
 tools/perf/builtin-report.c |  3 +++
 tools/perf/util/map.c   | 10 +-
 tools/perf/util/symbol.c|  7 +++
 tools/perf/util/symbol.h|  2 ++
 4 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 348bed4..9b506af 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -685,6 +685,9 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
   "only consider these symbols"),
OPT_STRING(0, "symbol-filter", _filter_str, "filter",
   "only show symbols that (partially) match with this filter"),
+OPT_STRING(0, "hugetlb-file", _conf.hugetlb_list_str, 
"file[,file...]",
+   "These files would be recoginized as files in hugetlbfs,"
+  "and JIT would be used for symbol-parsing"),
OPT_STRING('w', "column-widths", _conf.col_width_list_str,
   "width[,width...]",
   "don't try to adjust column width, use these fixed values"),
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index b5a5e9c..f919a3ad 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -30,11 +30,19 @@ static inline int is_anon_memory(const char *filename)
   !strcmp(filename, "/anon_hugepage (deleted)");
 }
 
+static inline int is_hugetlb_memory(const char *filename)
+{
+   return (symbol_conf.hugetlb_list != NULL) && 
+   (strlist__has_entry(symbol_conf.hugetlb_list,
+   filename));
+}
+
 static inline int is_no_dso_memory(const char *filename)
 {
return !strncmp(filename, "[stack", 6) ||
   !strncmp(filename, "/SYSV",5)   ||
-  !strcmp(filename, "[heap]");
+  !strcmp(filename, "[heap]") ||
+  is_hugetlb_memory(filename);
 }
 
 static inline int is_android_lib(const char *filename)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 48b588c..c3855fd 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1990,6 +1990,10 @@ int symbol__init(struct perf_session_env *env)
   symbol_conf.sym_list_str, "symbol") < 0)
goto out_free_tid_list;
 
+   if (setup_list(_conf.hugetlb_list,
+  symbol_conf.hugetlb_list_str, "hugetlb") < 0)
+   goto out_free_hugetlb_list;
+
/*
 * A path to symbols of "/" is identical to ""
 * reset here for simplicity.
@@ -2007,6 +2011,8 @@ int symbol__init(struct perf_session_env *env)
symbol_conf.initialized = true;
return 0;
 
+out_free_hugetlb_list:
+   strlist__delete(symbol_conf.hugetlb_list);
 out_free_tid_list:
intlist__delete(symbol_conf.tid_list);
 out_free_pid_list:
@@ -2025,6 +2031,7 @@ void symbol__exit(void)
strlist__delete(symbol_conf.sym_list);
strlist__delete(symbol_conf.dso_list);
strlist__delete(symbol_conf.comm_list);
+   strlist__delete

Re: [RFC] perf tools: Add hugetlbfs memory recognition

[Hou Pengyang]

On 2015/6/29 21:42, Arnaldo Carvalho de Melo wrote:

Em Mon, Jun 29, 2015 at 10:23:29AM -0300, Arnaldo Carvalho de Melo escreveu:

Em Sat, Jun 27, 2015 at 05:08:20PM +0800, Hou Pengyang escreveu:

There is something about MAP_HUGETLB.



In this patch, we check if a mmap area is hugetlbfs area by MAP_HUGETLB,
a bit in MMAP2 event.



However, if mmap area is hugetlb related, MAP_HUGETLB does not always
appear. Because, there are two ways generating MMAP2 event.



1) when a new vm_area_struct is created, its info would be exported
as a MMAP2 event.
2) perf reads /proc/pid/maps for generating MMAP2 event.



MAP_HUGETLB appears if MMAP2 event is generated on situation 1),
while not on situation 2).



This is because on situation 2), perf reads /proc/pid/maps, which
contains only PROT_READ/WRITE/EXEC, MAP_SHARED/MAP_PRIVATE, while more
details appear in /proc/pid/smaps, such as MAP_HUGETLB.


Humm:

[root@zoo ~]# wc -l /proc/`pidof firefox`/maps
934 /proc/4551/maps
[root@zoo ~]# wc -l /proc/`pidof firefox`/smaps
14944 /proc/4551/smaps
[root@zoo ~]#


So I wonder if there is a need to read /proc/pid/smaps instead of
/proc/pid/maps to generate MMAP2 event. Or we should solve the problem by
another way?


Doing some research now...


Bummer, seems that only smaps -> ... -> show_smap_vma_flags() will
expose that to userspace...

Perhaps we can look at some global stat for HugeTLB fs to figure out if
we really, really need to parse smaps instead of just maps? I.e. in my
system, a desktop one, F21, I have:



It seems no other info tell us if one process is using hugetlbfs.
So how about an option to tell perf explicitly which file is from
hugetlbfs, like:

./perf report --hugetlb-file=/mnt/huge/hugepagefile

So that, we can check if a mmap area is from hugetlbfs by its name
instead of MAP_HUGETLB.


[root@zoo ~]# find /proc -name smaps | xargs grep -w ht
grep: /proc/31971/task/31971/smaps: No such file or directory
grep: /proc/31971/smaps: No such file or directory
[root@zoo ~]#

No "ht" HugeTLB areas, so no need to parse 16 times more bytes than by
just using /proc/PID/maps.






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

.




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

[PATCH v2] perf tools: Add hugetlbfs memory recognition

[Hou Pengyang]

Maps for JIT is helpful for symbols-parsing for anon-executable-memory.
What we need to do is to add (START, SIZE, symbolname) to /tmp/perf-%d.map
(%d = pid of process), and perf would parse symbol located in this area
according to /tmp/perf-%d.map. It works well for normal mmap.

However, when we alloc such memory from hugetlbfs by the following code:

..

fd = open(/mnt/huge/hugepagefile, O_CREAT | O_RDWR, 0755);
if (fd  0) {
perror(Open failed);
exit(1);
}   
addr = mmap(ADDR, LENGTH, PROT_READ | PROT_WRITE | \   
PROT_EXEC, MAP_SHARED, fd, 0); 

..
where hugetlbfs is mounted in /mnt/huge. Symbols could not be parsed correctly:

#perf report
   86.96% 0.00%  hugepage-mmap  hugepagefile  [.] 0xffe0005c
  
   86.96% 0.00%  hugepage-mmap  hugepagefile  [.] 0xffe000ac

This is because such mmap area's file backed is /mnt/huge/hugepagefile, a 
node 
in pseudo filesystem, it is useless for symbol-parsing. so wo had better 
recognize 
such hugetlbfs area, and rename it's filename to /tmp/perf-%d.map, just as 
anon-memory
and no_dso_memory do. 

This patch imports a new option named --hugetlb-file to let user tell perf
explicitly which file is in hugetlbfs, and mmap area whose backed filenode is 
in 
hugetlbfs would be recognized as memory without dso in function 
is_no_dso_memory. 

After this patch:
#perf report 
   86.96% 0.00%  hugepage-mmap  perf-182.map[.] 0x0020005c 
   86.96% 0.00%  hugepage-mmap  perf-182.map[.] 0x002000ac

We can add maps info to perf-182.map for further symbols-parsing.

Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
 tools/perf/builtin-report.c |  3 +++
 tools/perf/util/map.c   | 10 +-
 tools/perf/util/symbol.c|  7 +++
 tools/perf/util/symbol.h|  2 ++
 4 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 348bed4..9b506af 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -685,6 +685,9 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
   only consider these symbols),
OPT_STRING(0, symbol-filter, report.symbol_filter_str, filter,
   only show symbols that (partially) match with this filter),
+OPT_STRING(0, hugetlb-file, symbol_conf.hugetlb_list_str, 
file[,file...],
+   These files would be recoginized as files in hugetlbfs,
+  and JIT would be used for symbol-parsing),
OPT_STRING('w', column-widths, symbol_conf.col_width_list_str,
   width[,width...],
   don't try to adjust column width, use these fixed values),
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index b5a5e9c..f919a3ad 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -30,11 +30,19 @@ static inline int is_anon_memory(const char *filename)
   !strcmp(filename, /anon_hugepage (deleted));
 }
 
+static inline int is_hugetlb_memory(const char *filename)
+{
+   return (symbol_conf.hugetlb_list != NULL)  
+   (strlist__has_entry(symbol_conf.hugetlb_list,
+   filename));
+}
+
 static inline int is_no_dso_memory(const char *filename)
 {
return !strncmp(filename, [stack, 6) ||
   !strncmp(filename, /SYSV,5)   ||
-  !strcmp(filename, [heap]);
+  !strcmp(filename, [heap]) ||
+  is_hugetlb_memory(filename);
 }
 
 static inline int is_android_lib(const char *filename)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 48b588c..c3855fd 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1990,6 +1990,10 @@ int symbol__init(struct perf_session_env *env)
   symbol_conf.sym_list_str, symbol)  0)
goto out_free_tid_list;
 
+   if (setup_list(symbol_conf.hugetlb_list,
+  symbol_conf.hugetlb_list_str, hugetlb)  0)
+   goto out_free_hugetlb_list;
+
/*
 * A path to symbols of / is identical to 
 * reset here for simplicity.
@@ -2007,6 +2011,8 @@ int symbol__init(struct perf_session_env *env)
symbol_conf.initialized = true;
return 0;
 
+out_free_hugetlb_list:
+   strlist__delete(symbol_conf.hugetlb_list);
 out_free_tid_list:
intlist__delete(symbol_conf.tid_list);
 out_free_pid_list:
@@ -2025,6 +2031,7 @@ void symbol__exit(void)
strlist__delete(symbol_conf.sym_list);
strlist__delete(symbol_conf.dso_list);
strlist__delete(symbol_conf.comm_list);
+   strlist__delete(symbol_conf.hugetlb_list);
intlist__delete(symbol_conf.tid_list);
intlist__delete(symbol_conf.pid_list);
vmlinux_path__exit();
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index bef47ead..81fb99c 100644

Re: [RFC] perf tools: Add hugetlbfs memory recognition

[Hou Pengyang]

On 2015/6/29 21:42, Arnaldo Carvalho de Melo wrote:

Em Mon, Jun 29, 2015 at 10:23:29AM -0300, Arnaldo Carvalho de Melo escreveu:

Em Sat, Jun 27, 2015 at 05:08:20PM +0800, Hou Pengyang escreveu:

There is something about MAP_HUGETLB.



In this patch, we check if a mmap area is hugetlbfs area by MAP_HUGETLB,
a bit in MMAP2 event.



However, if mmap area is hugetlb related, MAP_HUGETLB does not always
appear. Because, there are two ways generating MMAP2 event.



1) when a new vm_area_struct is created, its info would be exported
as a MMAP2 event.
2) perf reads /proc/pid/maps for generating MMAP2 event.



MAP_HUGETLB appears if MMAP2 event is generated on situation 1),
while not on situation 2).



This is because on situation 2), perf reads /proc/pid/maps, which
contains only PROT_READ/WRITE/EXEC, MAP_SHARED/MAP_PRIVATE, while more
details appear in /proc/pid/smaps, such as MAP_HUGETLB.


Humm:

[root@zoo ~]# wc -l /proc/`pidof firefox`/maps
934 /proc/4551/maps
[root@zoo ~]# wc -l /proc/`pidof firefox`/smaps
14944 /proc/4551/smaps
[root@zoo ~]#


So I wonder if there is a need to read /proc/pid/smaps instead of
/proc/pid/maps to generate MMAP2 event. Or we should solve the problem by
another way?


Doing some research now...


Bummer, seems that only smaps - ... - show_smap_vma_flags() will
expose that to userspace...

Perhaps we can look at some global stat for HugeTLB fs to figure out if
we really, really need to parse smaps instead of just maps? I.e. in my
system, a desktop one, F21, I have:



It seems no other info tell us if one process is using hugetlbfs.
So how about an option to tell perf explicitly which file is from
hugetlbfs, like:

./perf report --hugetlb-file=/mnt/huge/hugepagefile

So that, we can check if a mmap area is from hugetlbfs by its name
instead of MAP_HUGETLB.


[root@zoo ~]# find /proc -name smaps | xargs grep -w ht
grep: /proc/31971/task/31971/smaps: No such file or directory
grep: /proc/31971/smaps: No such file or directory
[root@zoo ~]#

No ht HugeTLB areas, so no need to parse 16 times more bytes than by
just using /proc/PID/maps.






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

.




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

Re: [RFC] perf tools: Add hugetlbfs memory recognition

[Hou Pengyang]

On 2015/6/27 16:49, Hou Pengyang wrote:

Maps for JIT is helpful for symbols-parsing for anon-executable-memory.
What we need to do is to add (START, SIZE, symbolname) to /tmp/perf-%d.map
(%d = pid of process), and perf would parse symbol located in this area
according to /tmp/perf-%d.map. It works well for normal mmap.

However, when we alloc such memory from hugetlbfs by the following code:

..

 fd = open("/mnt/huge/hugepagefile", O_CREAT | O_RDWR, 0755);
 if (fd < 0) {
 perror("Open failed");
 exit(1);
 }
 addr = mmap(ADDR, LENGTH, PROT_READ | PROT_WRITE | \
 PROT_EXEC, MAP_SHARED, fd, 0);

..
where hugetlbfs is mounted in /mnt/huge. Symbols could not be parsed correctly:

#perf report
86.96% 0.00%  hugepage-mmap  hugepagefile  [.] 0xffe0005c
86.96% 0.00%  hugepage-mmap  hugepagefile  [.] 0xffe000ac

This is because such mmap area's file backed is "/mnt/huge/hugepagefile", a node
in pseudo filesystem, it is useless for symbol-parsing. so wo had better 
recognize
such hugetlbfs area, and rename it's filename to /tmp/perf-%d.map, just as 
anon-memory
and no_dso_memory do.

This patch imports a new function named is_hugetlb_memory to check if this 
memory
is from hugetlbfs. If true, change its name.

After this patch:
#perf report
86.96% 0.00%  hugepage-mmap  perf-182.map[.] 0x0020005c
86.96% 0.00%  hugepage-mmap  perf-182.map[.] 0x002000ac

We can add maps info to perf-182.map for further symbols-parsing.

Signed-off-by: Hou Pengyang 
---
  tools/perf/util/map.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index b5a5e9c..796db08 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -15,6 +15,7 @@
  #include "debug.h"
  #include "machine.h"
  #include 
+#include 

  static void __maps__insert(struct maps *maps, struct map *map);

@@ -43,6 +44,11 @@ static inline int is_android_lib(const char *filename)
   !strncmp(filename, "/system/lib", 11);
  }

+static inline int is_hugetlb_memory(u32 flags)
+{
+   return flags & MAP_HUGETLB;
+}


There is something about MAP_HUGETLB.

In this patch, we check if a mmap area is hugetlbfs area by MAP_HUGETLB,
a bit in MMAP2 event.

However, if mmap area is hugetlb related, MAP_HUGETLB does not always 
appear. Because, there are two ways generating MMAP2 event.


1) when a new vm_area_struct is created, its info would be exported
   as a MMAP2 event.
2) perf reads /proc/pid/maps for generating MMAP2 event.

MAP_HUGETLB appears if MMAP2 event is generated on situation 1),
while not on situation 2).

This is because on situation 2), perf reads /proc/pid/maps, which
contains only PROT_READ/WRITE/EXEC, MAP_SHARED/MAP_PRIVATE, while more 
details appear in /proc/pid/smaps, such as MAP_HUGETLB.


So I wonder if there is a need to read /proc/pid/smaps instead of 
/proc/pid/maps to generate MMAP2 event. Or we should solve the problem 
by another way?


Thanks!


+
  static inline bool replace_android_lib(const char *filename, char 
*newfilename)
  {
const char *libname;
@@ -151,12 +157,13 @@ struct map *map__new(struct machine *machine, u64 start, 
u64 len,
if (map != NULL) {
char newfilename[PATH_MAX];
struct dso *dso;
-   int anon, no_dso, vdso, android;
+   int anon, no_dso, vdso, android, hugetlb;

android = is_android_lib(filename);
anon = is_anon_memory(filename);
vdso = is_vdso_map(filename);
no_dso = is_no_dso_memory(filename);
+   hugetlb = is_hugetlb_memory(flags);

map->maj = d_maj;
map->min = d_min;
@@ -165,7 +172,7 @@ struct map *map__new(struct machine *machine, u64 start, 
u64 len,
map->prot = prot;
map->flags = flags;

-   if ((anon || no_dso) && type == MAP__FUNCTION) {
+   if ((anon || no_dso || hugetlb) && type == MAP__FUNCTION) {
snprintf(newfilename, sizeof(newfilename), 
"/tmp/perf-%d.map", pid);
filename = newfilename;
}




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

[RFC] perf tools: Add hugetlbfs memory recognition

[Hou Pengyang]

Maps for JIT is helpful for symbols-parsing for anon-executable-memory.
What we need to do is to add (START, SIZE, symbolname) to /tmp/perf-%d.map
(%d = pid of process), and perf would parse symbol located in this area
according to /tmp/perf-%d.map. It works well for normal mmap.

However, when we alloc such memory from hugetlbfs by the following code:

..

fd = open("/mnt/huge/hugepagefile", O_CREAT | O_RDWR, 0755);
if (fd < 0) {
perror("Open failed");
exit(1);
}   
addr = mmap(ADDR, LENGTH, PROT_READ | PROT_WRITE | \   
PROT_EXEC, MAP_SHARED, fd, 0); 

..
where hugetlbfs is mounted in /mnt/huge. Symbols could not be parsed correctly:

#perf report
   86.96% 0.00%  hugepage-mmap  hugepagefile  [.] 0xffe0005c
  
   86.96% 0.00%  hugepage-mmap  hugepagefile  [.] 0xffe000ac

This is because such mmap area's file backed is "/mnt/huge/hugepagefile", a 
node 
in pseudo filesystem, it is useless for symbol-parsing. so wo had better 
recognize 
such hugetlbfs area, and rename it's filename to /tmp/perf-%d.map, just as 
anon-memory
and no_dso_memory do. 

This patch imports a new function named is_hugetlb_memory to check if this 
memory
is from hugetlbfs. If true, change its name.  

After this patch:
#perf report 
   86.96% 0.00%  hugepage-mmap  perf-182.map[.] 0x0020005c 
   86.96% 0.00%  hugepage-mmap  perf-182.map[.] 0x002000ac

We can add maps info to perf-182.map for further symbols-parsing.

Signed-off-by: Hou Pengyang 
---
 tools/perf/util/map.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index b5a5e9c..796db08 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -15,6 +15,7 @@
 #include "debug.h"
 #include "machine.h"
 #include 
+#include 
 
 static void __maps__insert(struct maps *maps, struct map *map);
 
@@ -43,6 +44,11 @@ static inline int is_android_lib(const char *filename)
   !strncmp(filename, "/system/lib", 11);
 }
 
+static inline int is_hugetlb_memory(u32 flags)
+{
+   return flags & MAP_HUGETLB;
+}
+
 static inline bool replace_android_lib(const char *filename, char *newfilename)
 {
const char *libname;
@@ -151,12 +157,13 @@ struct map *map__new(struct machine *machine, u64 start, 
u64 len,
if (map != NULL) {
char newfilename[PATH_MAX];
struct dso *dso;
-   int anon, no_dso, vdso, android;
+   int anon, no_dso, vdso, android, hugetlb;
 
android = is_android_lib(filename);
anon = is_anon_memory(filename);
vdso = is_vdso_map(filename);
no_dso = is_no_dso_memory(filename);
+   hugetlb = is_hugetlb_memory(flags);
 
map->maj = d_maj;
map->min = d_min;
@@ -165,7 +172,7 @@ struct map *map__new(struct machine *machine, u64 start, 
u64 len,
map->prot = prot;
map->flags = flags;
 
-   if ((anon || no_dso) && type == MAP__FUNCTION) {
+   if ((anon || no_dso || hugetlb) && type == MAP__FUNCTION) {
snprintf(newfilename, sizeof(newfilename), 
"/tmp/perf-%d.map", pid);
filename = newfilename;
}
-- 
1.8.3.4

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

[RFC] perf tools: Add hugetlbfs memory recognition

[Hou Pengyang]

Maps for JIT is helpful for symbols-parsing for anon-executable-memory.
What we need to do is to add (START, SIZE, symbolname) to /tmp/perf-%d.map
(%d = pid of process), and perf would parse symbol located in this area
according to /tmp/perf-%d.map. It works well for normal mmap.

However, when we alloc such memory from hugetlbfs by the following code:

..

fd = open(/mnt/huge/hugepagefile, O_CREAT | O_RDWR, 0755);
if (fd  0) {
perror(Open failed);
exit(1);
}   
addr = mmap(ADDR, LENGTH, PROT_READ | PROT_WRITE | \   
PROT_EXEC, MAP_SHARED, fd, 0); 

..
where hugetlbfs is mounted in /mnt/huge. Symbols could not be parsed correctly:

#perf report
   86.96% 0.00%  hugepage-mmap  hugepagefile  [.] 0xffe0005c
  
   86.96% 0.00%  hugepage-mmap  hugepagefile  [.] 0xffe000ac

This is because such mmap area's file backed is /mnt/huge/hugepagefile, a 
node 
in pseudo filesystem, it is useless for symbol-parsing. so wo had better 
recognize 
such hugetlbfs area, and rename it's filename to /tmp/perf-%d.map, just as 
anon-memory
and no_dso_memory do. 

This patch imports a new function named is_hugetlb_memory to check if this 
memory
is from hugetlbfs. If true, change its name.  

After this patch:
#perf report 
   86.96% 0.00%  hugepage-mmap  perf-182.map[.] 0x0020005c 
   86.96% 0.00%  hugepage-mmap  perf-182.map[.] 0x002000ac

We can add maps info to perf-182.map for further symbols-parsing.

Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
 tools/perf/util/map.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index b5a5e9c..796db08 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -15,6 +15,7 @@
 #include debug.h
 #include machine.h
 #include linux/string.h
+#include sys/mman.h
 
 static void __maps__insert(struct maps *maps, struct map *map);
 
@@ -43,6 +44,11 @@ static inline int is_android_lib(const char *filename)
   !strncmp(filename, /system/lib, 11);
 }
 
+static inline int is_hugetlb_memory(u32 flags)
+{
+   return flags  MAP_HUGETLB;
+}
+
 static inline bool replace_android_lib(const char *filename, char *newfilename)
 {
const char *libname;
@@ -151,12 +157,13 @@ struct map *map__new(struct machine *machine, u64 start, 
u64 len,
if (map != NULL) {
char newfilename[PATH_MAX];
struct dso *dso;
-   int anon, no_dso, vdso, android;
+   int anon, no_dso, vdso, android, hugetlb;
 
android = is_android_lib(filename);
anon = is_anon_memory(filename);
vdso = is_vdso_map(filename);
no_dso = is_no_dso_memory(filename);
+   hugetlb = is_hugetlb_memory(flags);
 
map-maj = d_maj;
map-min = d_min;
@@ -165,7 +172,7 @@ struct map *map__new(struct machine *machine, u64 start, 
u64 len,
map-prot = prot;
map-flags = flags;
 
-   if ((anon || no_dso)  type == MAP__FUNCTION) {
+   if ((anon || no_dso || hugetlb)  type == MAP__FUNCTION) {
snprintf(newfilename, sizeof(newfilename), 
/tmp/perf-%d.map, pid);
filename = newfilename;
}
-- 
1.8.3.4

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

Re: [RFC] perf tools: Add hugetlbfs memory recognition

[Hou Pengyang]

On 2015/6/27 16:49, Hou Pengyang wrote:

Maps for JIT is helpful for symbols-parsing for anon-executable-memory.
What we need to do is to add (START, SIZE, symbolname) to /tmp/perf-%d.map
(%d = pid of process), and perf would parse symbol located in this area
according to /tmp/perf-%d.map. It works well for normal mmap.

However, when we alloc such memory from hugetlbfs by the following code:

..

 fd = open(/mnt/huge/hugepagefile, O_CREAT | O_RDWR, 0755);
 if (fd  0) {
 perror(Open failed);
 exit(1);
 }
 addr = mmap(ADDR, LENGTH, PROT_READ | PROT_WRITE | \
 PROT_EXEC, MAP_SHARED, fd, 0);

..
where hugetlbfs is mounted in /mnt/huge. Symbols could not be parsed correctly:

#perf report
86.96% 0.00%  hugepage-mmap  hugepagefile  [.] 0xffe0005c
86.96% 0.00%  hugepage-mmap  hugepagefile  [.] 0xffe000ac

This is because such mmap area's file backed is /mnt/huge/hugepagefile, a node
in pseudo filesystem, it is useless for symbol-parsing. so wo had better 
recognize
such hugetlbfs area, and rename it's filename to /tmp/perf-%d.map, just as 
anon-memory
and no_dso_memory do.

This patch imports a new function named is_hugetlb_memory to check if this 
memory
is from hugetlbfs. If true, change its name.

After this patch:
#perf report
86.96% 0.00%  hugepage-mmap  perf-182.map[.] 0x0020005c
86.96% 0.00%  hugepage-mmap  perf-182.map[.] 0x002000ac

We can add maps info to perf-182.map for further symbols-parsing.

Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
  tools/perf/util/map.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index b5a5e9c..796db08 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -15,6 +15,7 @@
  #include debug.h
  #include machine.h
  #include linux/string.h
+#include sys/mman.h

  static void __maps__insert(struct maps *maps, struct map *map);

@@ -43,6 +44,11 @@ static inline int is_android_lib(const char *filename)
   !strncmp(filename, /system/lib, 11);
  }

+static inline int is_hugetlb_memory(u32 flags)
+{
+   return flags  MAP_HUGETLB;
+}


There is something about MAP_HUGETLB.

In this patch, we check if a mmap area is hugetlbfs area by MAP_HUGETLB,
a bit in MMAP2 event.

However, if mmap area is hugetlb related, MAP_HUGETLB does not always 
appear. Because, there are two ways generating MMAP2 event.


1) when a new vm_area_struct is created, its info would be exported
   as a MMAP2 event.
2) perf reads /proc/pid/maps for generating MMAP2 event.

MAP_HUGETLB appears if MMAP2 event is generated on situation 1),
while not on situation 2).

This is because on situation 2), perf reads /proc/pid/maps, which
contains only PROT_READ/WRITE/EXEC, MAP_SHARED/MAP_PRIVATE, while more 
details appear in /proc/pid/smaps, such as MAP_HUGETLB.


So I wonder if there is a need to read /proc/pid/smaps instead of 
/proc/pid/maps to generate MMAP2 event. Or we should solve the problem 
by another way?


Thanks!


+
  static inline bool replace_android_lib(const char *filename, char 
*newfilename)
  {
const char *libname;
@@ -151,12 +157,13 @@ struct map *map__new(struct machine *machine, u64 start, 
u64 len,
if (map != NULL) {
char newfilename[PATH_MAX];
struct dso *dso;
-   int anon, no_dso, vdso, android;
+   int anon, no_dso, vdso, android, hugetlb;

android = is_android_lib(filename);
anon = is_anon_memory(filename);
vdso = is_vdso_map(filename);
no_dso = is_no_dso_memory(filename);
+   hugetlb = is_hugetlb_memory(flags);

map-maj = d_maj;
map-min = d_min;
@@ -165,7 +172,7 @@ struct map *map__new(struct machine *machine, u64 start, 
u64 len,
map-prot = prot;
map-flags = flags;

-   if ((anon || no_dso)  type == MAP__FUNCTION) {
+   if ((anon || no_dso || hugetlb)  type == MAP__FUNCTION) {
snprintf(newfilename, sizeof(newfilename), 
/tmp/perf-%d.map, pid);
filename = newfilename;
}




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

Re: [RFC] perf report: introduce --map-anon-mem for anon-executable-memory symbols parsing

[Hou Pengyang]

On 2015/6/19 18:42, Ingo Molnar wrote:


* Wangnan (F)  wrote:


On 2015/6/18 22:01, Hou Pengyang wrote:

This patch introduces a --map-anon-mem argument to perf report to deal
with anon-executable-memory symbol parsing.


--map-anon-mem is not a good name. The user defined map area list
introduced in this patch can be used on not only anon mapping but
also file mapping.


Yeah, so quirky options generally suck and only 0.01% of the users will use it.
It's in a way worse than not having this code, because we'll have to maintain 
it,
but it won't be used.

Is there a way to auto-detect 'executable anon mappings' (perhaps by generating 
an
MMAP event with some extra bit set, or a new MMAP event?) so that it's all
seemless?


I think it not difficult to generate such MMAP event, just like :

	0 435090424309600 0x3e0 [0x68]: PERF_RECORD_MMAP2 
788/788:[0x7f946c(0x4000) @ 0x7f946c 00:00 0 0]: ---p //anon


But for symbol parsing, this is not enough. For such mmap area, perf
doesn't know the path of '.so/.o', which is necessarcy for symbol-
parsing. So we need to tell perf the relationship between the .so file 
and the mmap range explicitly.


Thanks,
 Hou


The user should not be required to know about such details!

Thanks,

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





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] perf report: introduce --map-anon-mem for anon-executable-memory symbols parsing

[Hou Pengyang]

On 2015/6/19 18:42, Ingo Molnar wrote:


* Wangnan (F) wangn...@huawei.com wrote:


On 2015/6/18 22:01, Hou Pengyang wrote:

This patch introduces a --map-anon-mem argument to perf report to deal
with anon-executable-memory symbol parsing.


--map-anon-mem is not a good name. The user defined map area list
introduced in this patch can be used on not only anon mapping but
also file mapping.


Yeah, so quirky options generally suck and only 0.01% of the users will use it.
It's in a way worse than not having this code, because we'll have to maintain 
it,
but it won't be used.

Is there a way to auto-detect 'executable anon mappings' (perhaps by generating 
an
MMAP event with some extra bit set, or a new MMAP event?) so that it's all
seemless?


I think it not difficult to generate such MMAP event, just like :

	0 435090424309600 0x3e0 [0x68]: PERF_RECORD_MMAP2 
788/788:[0x7f946c(0x4000) @ 0x7f946c 00:00 0 0]: ---p //anon


But for symbol parsing, this is not enough. For such mmap area, perf
doesn't know the path of '.so/.o', which is necessarcy for symbol-
parsing. So we need to tell perf the relationship between the .so file 
and the mmap range explicitly.


Thanks,
 Hou


The user should not be required to know about such details!

Thanks,

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





--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] perf report: introduce --map-anon-mem for anon-executable-memory symbols parsing

[Hou Pengyang]

This patch introduces a --map-anon-mem argument to perf report to deal
with anon-executable-memory symbol parsing.

Sometimes, we mmap() executable memory area, and copy some '.so' or '.o'
files to the area, and then do the relocation and code fixing to make the 
code work well. However, perf could not parse symbol info in those files,
since the memory area is not file-backended.

The problem was first discussed in :
https://lkml.org/lkml/2015/4/1/203

In this discussion, we finally preferred to something like 'perf inject' 
to inject fake mmap events into perf.data. However, for embeded system 
whose space is limited, it's not so wise to make another big perf.data
by 'perf inject'. So we still adopt the previous solution: introduce 
'--map-anon-mem' argument and let user directly hint perf-report about
the private mapping info.

The content of this patch:
 1) A new field mapping_strlist is introduced to struct report, in order
to store --map-anon-mem string for afterwards parsing.
 2) A new field maps_anon is introduced to struct map_groups. maps_anon is used
to store the maps user defines directly for anon-mapping. when 
searching maps
in map_groups, we prefer to the maps stored in maps_anon.
 3) The main part of this patch resides in builtin-report.c and session.c.
the part in builtin-report.c is charge of storing --map-anon-mem string,
while the part in session.c parses the string, create maps, and store maps
in map_groups->maps_anon.

Here is an example:
 $ perf report --map-anon-mem=./libtesta.o@257,0x7f864c,0x60,0 \

--map-anon-mem=./libtestb.o@257,0x7f864c0060,0x1000,0 

Where 257 is the pid and 0x76864c is private map area got through:

mmap(NULL, 4096 * 4, PROT_EXEC|PROT_WRITE|PROT_READ, 
MAP_ANONYMOUS|MAP_PRIVATE, \
  -1, 0);

and libtesta.o is copied to [0x7f864c,0x7f864c0060), 
libtestb.o is copied to [0x7f864c0060,0x7f864c1060).

Signed-off-by: Wang Nan 
Signed-off-by: Hou Pengyang 
---
 tools/perf/Documentation/perf-report.txt |   8 +++
 tools/perf/builtin-report.c  |  39 +++
 tools/perf/util/map.c|   3 +-
 tools/perf/util/map.h|  10 ++-
 tools/perf/util/session.c| 117 +++
 tools/perf/util/session.h|   4 ++
 6 files changed, 178 insertions(+), 3 deletions(-)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index c33b69f..78df4eb 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -353,6 +353,15 @@ OPTIONS
 
To disable decoding entirely, use --no-itrace.
 
+--map-anon-mem=objfile@pid,start,length[,pgoff]::
+   Give memory layout hints for specific process. This makes
+   perf regard provided range of memory as mapped from provided
+   file instead of its original attributes found in perf.data.
+   pid is necessary, since mmap address is meaningless for other process.
+   start and length represent the address range. pgoff represent mapping
+   offset of that file, default value is 0 (map from start of the file).
+   pid should be decimal, while for start, length, and pgoff, both
+   decimal and hexadecimal are avaliable.
 
 include::callchain-overhead-calculation.txt[]
 
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 32626ea..5b6ea06 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -62,6 +62,7 @@ struct report {
u64 nr_entries;
u64 queue_size;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
+   struct strlist  *mapping_strlist;
 };
 
 static int report__config(const char *var, const char *value, void *cb)
@@ -586,6 +587,32 @@ parse_percent_limit(const struct option *opt, const char 
*str,
return 0;
 }
 
+static int
+append_to_strlist(const struct option *opt, const char *str,
+ int unset __maybe_unused)
+{
+   struct strlist **pslist = (struct strlist **)opt->value;
+   struct strlist *s;
+   int err;
+
+   if (!str)
+   return -1;
+
+   if (!*pslist)
+   *pslist = strlist__new(true, NULL);
+
+   s = *pslist;
+
+   if (!s) {
+   pr_err("No enough memory: can't alloc strlist\n");
+   return -ENOMEM;
+   }
+
+   err = strlist__add(s, str);
+   return err;
+}
+
+
 int cmd_report(int argc, const char **argv, const char *prefix __maybe_unused)
 {
struct perf_session *session;
@@ -728,6 +755,10 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
OPT_CALLBACK_OPTARG(0, "itrace", _synth_opts, NULL, "opts",
"Instruction Tracing options",
itrace_parse_synth_opts)

[tip:perf/core] perf unwind: Fix a compile error

[tip-bot for Hou Pengyang]

Commit-ID:  f005813afb89bae92faf254130c544dc68984c6b
Gitweb: http://git.kernel.org/tip/f005813afb89bae92faf254130c544dc68984c6b
Author: Hou Pengyang 
AuthorDate: Tue, 16 Jun 2015 11:16:35 +
Committer:  Arnaldo Carvalho de Melo 
CommitDate: Tue, 16 Jun 2015 10:40:03 -0300

perf unwind: Fix a compile error

When libunwind is on, there is a compile error as :

  util/unwind-libunwind.c:363:21: error: 'dso' undeclared (first use in this 
function)
  dso__data_put_fd(dso);

This patch fixes it.

Signed-off-by: Hou Pengyang 
Cc: Namhyung Kim 
Cc: Wang Nan 
Fixes: 4bb11d012ab248d0 ("perf tools: Add dso__data_get/put_fd()")
Link: 
http://lkml.kernel.org/r/1434453395-10560-1-git-send-email-houpengy...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/unwind-libunwind.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/unwind-libunwind.c 
b/tools/perf/util/unwind-libunwind.c
index f079b63..4c00507 100644
--- a/tools/perf/util/unwind-libunwind.c
+++ b/tools/perf/util/unwind-libunwind.c
@@ -360,7 +360,7 @@ find_proc_info(unw_addr_space_t as, unw_word_t ip, 
unw_proc_info_t *pi,
unw_word_t base = is_exec ? 0 : map->start;
 
if (fd >= 0)
-   dso__data_put_fd(dso);
+   dso__data_put_fd(map->dso);
 
memset(, 0, sizeof(di));
if (dwarf_find_debug_frame(0, , ip, base, map->dso->name,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] perf report: introduce --map-anon-mem for anon-executable-memory symbols parsing

[Hou Pengyang]

This patch introduces a --map-anon-mem argument to perf report to deal
with anon-executable-memory symbol parsing.

Sometimes, we mmap() executable memory area, and copy some '.so' or '.o'
files to the area, and then do the relocation and code fixing to make the 
code work well. However, perf could not parse symbol info in those files,
since the memory area is not file-backended.

The problem was first discussed in :
https://lkml.org/lkml/2015/4/1/203

In this discussion, we finally preferred to something like 'perf inject' 
to inject fake mmap events into perf.data. However, for embeded system 
whose space is limited, it's not so wise to make another big perf.data
by 'perf inject'. So we still adopt the previous solution: introduce 
'--map-anon-mem' argument and let user directly hint perf-report about
the private mapping info.

The content of this patch:
 1) A new field mapping_strlist is introduced to struct report, in order
to store --map-anon-mem string for afterwards parsing.
 2) A new field maps_anon is introduced to struct map_groups. maps_anon is used
to store the maps user defines directly for anon-mapping. when 
searching maps
in map_groups, we prefer to the maps stored in maps_anon.
 3) The main part of this patch resides in builtin-report.c and session.c.
the part in builtin-report.c is charge of storing --map-anon-mem string,
while the part in session.c parses the string, create maps, and store maps
in map_groups-maps_anon.

Here is an example:
 $ perf report --map-anon-mem=./libtesta.o@257,0x7f864c,0x60,0 \

--map-anon-mem=./libtestb.o@257,0x7f864c0060,0x1000,0 

Where 257 is the pid and 0x76864c is private map area got through:

mmap(NULL, 4096 * 4, PROT_EXEC|PROT_WRITE|PROT_READ, 
MAP_ANONYMOUS|MAP_PRIVATE, \
  -1, 0);

and libtesta.o is copied to [0x7f864c,0x7f864c0060), 
libtestb.o is copied to [0x7f864c0060,0x7f864c1060).

Signed-off-by: Wang Nan wangn...@huawei.com
Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
 tools/perf/Documentation/perf-report.txt |   8 +++
 tools/perf/builtin-report.c  |  39 +++
 tools/perf/util/map.c|   3 +-
 tools/perf/util/map.h|  10 ++-
 tools/perf/util/session.c| 117 +++
 tools/perf/util/session.h|   4 ++
 6 files changed, 178 insertions(+), 3 deletions(-)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index c33b69f..78df4eb 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -353,6 +353,15 @@ OPTIONS
 
To disable decoding entirely, use --no-itrace.
 
+--map-anon-mem=objfile@pid,start,length[,pgoff]::
+   Give memory layout hints for specific process. This makes
+   perf regard provided range of memory as mapped from provided
+   file instead of its original attributes found in perf.data.
+   pid is necessary, since mmap address is meaningless for other process.
+   start and length represent the address range. pgoff represent mapping
+   offset of that file, default value is 0 (map from start of the file).
+   pid should be decimal, while for start, length, and pgoff, both
+   decimal and hexadecimal are avaliable.
 
 include::callchain-overhead-calculation.txt[]
 
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 32626ea..5b6ea06 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -62,6 +62,7 @@ struct report {
u64 nr_entries;
u64 queue_size;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
+   struct strlist  *mapping_strlist;
 };
 
 static int report__config(const char *var, const char *value, void *cb)
@@ -586,6 +587,32 @@ parse_percent_limit(const struct option *opt, const char 
*str,
return 0;
 }
 
+static int
+append_to_strlist(const struct option *opt, const char *str,
+ int unset __maybe_unused)
+{
+   struct strlist **pslist = (struct strlist **)opt-value;
+   struct strlist *s;
+   int err;
+
+   if (!str)
+   return -1;
+
+   if (!*pslist)
+   *pslist = strlist__new(true, NULL);
+
+   s = *pslist;
+
+   if (!s) {
+   pr_err(No enough memory: can't alloc strlist\n);
+   return -ENOMEM;
+   }
+
+   err = strlist__add(s, str);
+   return err;
+}
+
+
 int cmd_report(int argc, const char **argv, const char *prefix __maybe_unused)
 {
struct perf_session *session;
@@ -728,6 +755,10 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
OPT_CALLBACK_OPTARG(0, itrace, itrace_synth_opts, NULL, opts,
Instruction Tracing options,
itrace_parse_synth_opts

[tip:perf/core] perf unwind: Fix a compile error

[tip-bot for Hou Pengyang]

Commit-ID:  f005813afb89bae92faf254130c544dc68984c6b
Gitweb: http://git.kernel.org/tip/f005813afb89bae92faf254130c544dc68984c6b
Author: Hou Pengyang houpengy...@huawei.com
AuthorDate: Tue, 16 Jun 2015 11:16:35 +
Committer:  Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Tue, 16 Jun 2015 10:40:03 -0300

perf unwind: Fix a compile error

When libunwind is on, there is a compile error as :

  util/unwind-libunwind.c:363:21: error: 'dso' undeclared (first use in this 
function)
  dso__data_put_fd(dso);

This patch fixes it.

Signed-off-by: Hou Pengyang houpengy...@huawei.com
Cc: Namhyung Kim namhy...@kernel.org
Cc: Wang Nan wangn...@huawei.com
Fixes: 4bb11d012ab248d0 (perf tools: Add dso__data_get/put_fd())
Link: 
http://lkml.kernel.org/r/1434453395-10560-1-git-send-email-houpengy...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
 tools/perf/util/unwind-libunwind.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/unwind-libunwind.c 
b/tools/perf/util/unwind-libunwind.c
index f079b63..4c00507 100644
--- a/tools/perf/util/unwind-libunwind.c
+++ b/tools/perf/util/unwind-libunwind.c
@@ -360,7 +360,7 @@ find_proc_info(unw_addr_space_t as, unw_word_t ip, 
unw_proc_info_t *pi,
unw_word_t base = is_exec ? 0 : map-start;
 
if (fd = 0)
-   dso__data_put_fd(dso);
+   dso__data_put_fd(map-dso);
 
memset(di, 0, sizeof(di));
if (dwarf_find_debug_frame(0, di, ip, base, map-dso-name,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] perf unwind: Fix a compile error

[Hou Pengyang]

When libunwind is on, there is a compile error as :

util/unwind-libunwind.c:363:21: error: 'dso' undeclared (first use in this 
function)
dso__data_put_fd(dso);

This patch fix it.

Fixes: 4bb11d012ab248d0 ("perf tools: Add dso__data_get/put_fd()")
Signed-off-by: Hou Pengyang 
---
 tools/perf/util/unwind-libunwind.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/unwind-libunwind.c 
b/tools/perf/util/unwind-libunwind.c
index f079b63..4c00507 100644
--- a/tools/perf/util/unwind-libunwind.c
+++ b/tools/perf/util/unwind-libunwind.c
@@ -360,7 +360,7 @@ find_proc_info(unw_addr_space_t as, unw_word_t ip, 
unw_proc_info_t *pi,
unw_word_t base = is_exec ? 0 : map->start;
 
if (fd >= 0)
-   dso__data_put_fd(dso);
+   dso__data_put_fd(map->dso);
 
memset(, 0, sizeof(di));
if (dwarf_find_debug_frame(0, , ip, base, map->dso->name,
-- 
1.8.5.2

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

[PATCH] perf unwind: Fix a compile error

[Hou Pengyang]

When libunwind is on, there is a compile error as :

util/unwind-libunwind.c:363:21: error: 'dso' undeclared (first use in this 
function)
dso__data_put_fd(dso);

This patch fix it.

Fixes: 4bb11d012ab248d0 (perf tools: Add dso__data_get/put_fd())
Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
 tools/perf/util/unwind-libunwind.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/unwind-libunwind.c 
b/tools/perf/util/unwind-libunwind.c
index f079b63..4c00507 100644
--- a/tools/perf/util/unwind-libunwind.c
+++ b/tools/perf/util/unwind-libunwind.c
@@ -360,7 +360,7 @@ find_proc_info(unw_addr_space_t as, unw_word_t ip, 
unw_proc_info_t *pi,
unw_word_t base = is_exec ? 0 : map-start;
 
if (fd = 0)
-   dso__data_put_fd(dso);
+   dso__data_put_fd(map-dso);
 
memset(di, 0, sizeof(di));
if (dwarf_find_debug_frame(0, di, ip, base, map-dso-name,
-- 
1.8.5.2

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

[PATCH v5] arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For ARM64, when tracing with tracepoint events, the IP and pstate are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
 ./perf report -f
Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194
Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and spsr .

With this patch, callchain can be parsed correctly as follows:

 ..
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] vfs_symlink
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] follow_down
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_get
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] do_execveat_common.isra.33
-2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_send_policy_notify
 pfkey_send_policy_notify
 pfkey_get
 v9fs_vfs_rename
 page_follow_link_light
 link_path_walk
 el0_svc_naked
...

Signed-off-by: Hou Pengyang 
Acked-by: Will Deacon 
---
 arch/arm64/include/asm/perf_event.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/include/asm/perf_event.h 
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..6471773 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   (regs)->pc = (__ip);\
+   (regs)->regs[29] = (unsigned long) __builtin_frame_address(0); \
+   (regs)->sp = current_stack_pointer; \
+   (regs)->pstate = PSR_MODE_EL1h; \
+}
+
 #endif
-- 
1.8.5.2

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

[PATCH v5] arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For ARM64, when tracing with tracepoint events, the IP and pstate are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
 ./perf report -f
Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194
Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and spsr .

With this patch, callchain can be parsed correctly as follows:

 ..
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] vfs_symlink
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] follow_down
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_get
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] do_execveat_common.isra.33
-2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_send_policy_notify
 pfkey_send_policy_notify
 pfkey_get
 v9fs_vfs_rename
 page_follow_link_light
 link_path_walk
 el0_svc_naked
...

Signed-off-by: Hou Pengyang houpengy...@huawei.com
Acked-by: Will Deacon will.dea...@arm.com
---
 arch/arm64/include/asm/perf_event.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/include/asm/perf_event.h 
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..6471773 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   (regs)-pc = (__ip);\
+   (regs)-regs[29] = (unsigned long) __builtin_frame_address(0); \
+   (regs)-sp = current_stack_pointer; \
+   (regs)-pstate = PSR_MODE_EL1h; \
+}
+
 #endif
-- 
1.8.5.2

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

[PATCH v4 1/2] arm: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For ARM, when tracing with tracepoint events, the IP and cpsr are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.006 MB perf.data ]
 ./perf report -f
Samples: 5  of event 'sched:sched_switch', Event count (approx.): 5
Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and cpsr.

With this patch, callchain can be parsed correctly as :

   .
-  100.00%   100.00%  ls   [kernel.kallsyms]  [k] __sched_text_start
   + __sched_text_start
+   20.00% 0.00%  ls   libc-2.18.so   [.] _dl_addr
+   20.00% 0.00%  ls   libc-2.18.so   [.] write
   .

Jean Pihet found this in ARM and come up with a patch:
http://thread.gmane.org/gmane.linux.kernel/1734283/focus=1734280

This patch rewrite Jean's patch in C.

Signed-off-by: Hou Pengyang 
---
 arch/arm/include/asm/perf_event.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/perf_event.h 
b/arch/arm/include/asm/perf_event.h
index d9cf138..4f9dec4 100644
--- a/arch/arm/include/asm/perf_event.h
+++ b/arch/arm/include/asm/perf_event.h
@@ -19,4 +19,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   (regs)->ARM_pc = (__ip); \
+   (regs)->ARM_fp = (unsigned long) __builtin_frame_address(0); \
+   (regs)->ARM_sp = current_stack_pointer; \
+   (regs)->ARM_cpsr = SVC_MODE; \
+}
+
 #endif /* __ARM_PERF_EVENT_H__ */
-- 
1.8.3.4

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

[PATCH v4 0/2] arm & arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For arm & arm64, when tracing with tracepoint events, the IP and cpsr 
are set to 0, preventing the perf code parsing the callchain and 
resolving the symbols correctly. 

These two patches fix this by implementing perf_arch_fetch_caller_regs
for arm and arm64, which fills several necessary register info for 
callchain unwinding and symbol resolving.

v3->v4:
 - fix compile errors

v2->v3:
 - split the original patch into two, one for arm and the other arm64;
 - change '|=' to '=' when setting cpsr. 

Hou Pengyang (2):
  arm: perf: Fix callchain parse error with kernel tracepoint events
  arm64: perf: Fix callchain parse error with kernel tracepoint events

 arch/arm/include/asm/perf_event.h   | 7 +++
 arch/arm64/include/asm/perf_event.h | 7 +++
 2 files changed, 14 insertions(+)

-- 
1.8.3.4

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

[PATCH v4 2/2] arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For ARM64, when tracing with tracepoint events, the IP and pstate are set
to 0, preventing the perf code parsing the callchain and resolving the 
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
 ./perf report -f
Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194 
Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and spsr .

With this patch, callchain can be parsed correctly as follows:

 ..
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] vfs_symlink
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] follow_down
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_get
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] do_execveat_common.isra.33
-2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_send_policy_notify
 pfkey_send_policy_notify
 pfkey_get
 v9fs_vfs_rename
 page_follow_link_light
 link_path_walk
 el0_svc_naked
...

Signed-off-by: Hou Pengyang 
---
 arch/arm64/include/asm/perf_event.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/include/asm/perf_event.h 
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..6471773 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   (regs)->pc = (__ip);\
+   (regs)->regs[AARCH64_INSN_REG_FP] = (unsigned long) 
__builtin_frame_address(0); \
+   (regs)->sp = current_stack_pointer; \
+   (regs)->pstate = PSR_MODE_EL1h; \
+}
+
 #endif
-- 
1.8.3.4

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

[PATCH v4 1/2] arm: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For ARM, when tracing with tracepoint events, the IP and cpsr are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.006 MB perf.data ]
 ./perf report -f
Samples: 5  of event 'sched:sched_switch', Event count (approx.): 5
Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and cpsr.

With this patch, callchain can be parsed correctly as :

   .
-  100.00%   100.00%  ls   [kernel.kallsyms]  [k] __sched_text_start
   + __sched_text_start
+   20.00% 0.00%  ls   libc-2.18.so   [.] _dl_addr
+   20.00% 0.00%  ls   libc-2.18.so   [.] write
   .

Jean Pihet found this in ARM and come up with a patch:
http://thread.gmane.org/gmane.linux.kernel/1734283/focus=1734280

This patch rewrite Jean's patch in C.

Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
 arch/arm/include/asm/perf_event.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/perf_event.h 
b/arch/arm/include/asm/perf_event.h
index d9cf138..4f9dec4 100644
--- a/arch/arm/include/asm/perf_event.h
+++ b/arch/arm/include/asm/perf_event.h
@@ -19,4 +19,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   (regs)-ARM_pc = (__ip); \
+   (regs)-ARM_fp = (unsigned long) __builtin_frame_address(0); \
+   (regs)-ARM_sp = current_stack_pointer; \
+   (regs)-ARM_cpsr = SVC_MODE; \
+}
+
 #endif /* __ARM_PERF_EVENT_H__ */
-- 
1.8.3.4

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

[PATCH v4 0/2] arm arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For arm  arm64, when tracing with tracepoint events, the IP and cpsr 
are set to 0, preventing the perf code parsing the callchain and 
resolving the symbols correctly. 

These two patches fix this by implementing perf_arch_fetch_caller_regs
for arm and arm64, which fills several necessary register info for 
callchain unwinding and symbol resolving.

v3-v4:
 - fix compile errors

v2-v3:
 - split the original patch into two, one for arm and the other arm64;
 - change '|=' to '=' when setting cpsr. 

Hou Pengyang (2):
  arm: perf: Fix callchain parse error with kernel tracepoint events
  arm64: perf: Fix callchain parse error with kernel tracepoint events

 arch/arm/include/asm/perf_event.h   | 7 +++
 arch/arm64/include/asm/perf_event.h | 7 +++
 2 files changed, 14 insertions(+)

-- 
1.8.3.4

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

[PATCH v4 2/2] arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For ARM64, when tracing with tracepoint events, the IP and pstate are set
to 0, preventing the perf code parsing the callchain and resolving the 
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
 ./perf report -f
Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194 
Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and spsr .

With this patch, callchain can be parsed correctly as follows:

 ..
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] vfs_symlink
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] follow_down
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_get
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] do_execveat_common.isra.33
-2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_send_policy_notify
 pfkey_send_policy_notify
 pfkey_get
 v9fs_vfs_rename
 page_follow_link_light
 link_path_walk
 el0_svc_naked
...

Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
 arch/arm64/include/asm/perf_event.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/include/asm/perf_event.h 
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..6471773 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   (regs)-pc = (__ip);\
+   (regs)-regs[AARCH64_INSN_REG_FP] = (unsigned long) 
__builtin_frame_address(0); \
+   (regs)-sp = current_stack_pointer; \
+   (regs)-pstate = PSR_MODE_EL1h; \
+}
+
 #endif
-- 
1.8.3.4

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

Re: [PATCH v3 2/2] arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

On 2015/5/6 1:00, Will Deacon wrote:

On Sat, May 02, 2015 at 06:58:17AM +0100, Hou Pengyang wrote:

For ARM64, when tracing with tracepoint events, the IP and pstate are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

  ./perf record -e sched:sched_switch -g --call-graph dwarf ls
 [ perf record: Captured and wrote 0.146 MB perf.data ]
  ./perf report -f
 Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194
 Children  SelfCommand  Shared Object Symbol
 100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and spsr .

With this patch, callchain can be parsed correctly as follows:

  ..
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] vfs_symlink
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] follow_down
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_get
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] do_execveat_common.isra.33
-2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_send_policy_notify
  pfkey_send_policy_notify
  pfkey_get
  v9fs_vfs_rename
  page_follow_link_light
  link_path_walk
  el0_svc_naked
 ...

Signed-off-by: Hou Pengyang 
---
  arch/arm64/include/asm/perf_event.h | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm64/include/asm/perf_event.h 
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..cc92021 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
  #define perf_misc_flags(regs) perf_misc_flags(regs)
  #endif

+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   (regs)->ARM_pc = (__ip);\
+   (regs)->ARM_fp = (unsigned long) __builtin_frame_address(0); \
+   (regs)->ARM_sp = current_stack_pointer; \
+   (regs)->ARM_cpsr = PSR_MODE_EL1h;\
+}


This can't possibly compile, therefore you can't possibly have tested it.


I am so sorry. I did test the patch, but on mainline 4.0 +
David long's patches for ARM64 kprobe which are not included in
mainline now. In David's patches, there are macros like ARM_pc, ARM_fp, 
ARM_sp and ARM_cpsr, my patch incorrectly used these macros which

results in such compile errors if applied to 4.0 directly:
error: 'struct pt_regs' has no member named 'ARM_pc'
error: 'struct pt_regs' has no member named 'ARM_fp'
error: 'struct pt_regs' has no member named 'ARM_sp'
error: 'struct pt_regs' has no member named 'ARM_cpsr'

I will fix the code and do more test.



Please fix the code and actually check that you're getting sensible
callchains before sending a new version of the patch.

Thanks,

Will

.




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

Re: [PATCH v3 2/2] arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

On 2015/5/6 1:00, Will Deacon wrote:

On Sat, May 02, 2015 at 06:58:17AM +0100, Hou Pengyang wrote:

For ARM64, when tracing with tracepoint events, the IP and pstate are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

  ./perf record -e sched:sched_switch -g --call-graph dwarf ls
 [ perf record: Captured and wrote 0.146 MB perf.data ]
  ./perf report -f
 Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194
 Children  SelfCommand  Shared Object Symbol
 100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and spsr .

With this patch, callchain can be parsed correctly as follows:

  ..
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] vfs_symlink
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] follow_down
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_get
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] do_execveat_common.isra.33
-2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_send_policy_notify
  pfkey_send_policy_notify
  pfkey_get
  v9fs_vfs_rename
  page_follow_link_light
  link_path_walk
  el0_svc_naked
 ...

Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
  arch/arm64/include/asm/perf_event.h | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm64/include/asm/perf_event.h 
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..cc92021 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
  #define perf_misc_flags(regs) perf_misc_flags(regs)
  #endif

+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   (regs)-ARM_pc = (__ip);\
+   (regs)-ARM_fp = (unsigned long) __builtin_frame_address(0); \
+   (regs)-ARM_sp = current_stack_pointer; \
+   (regs)-ARM_cpsr = PSR_MODE_EL1h;\
+}


This can't possibly compile, therefore you can't possibly have tested it.


I am so sorry. I did test the patch, but on mainline 4.0 +
David long's patches for ARM64 kprobe which are not included in
mainline now. In David's patches, there are macros like ARM_pc, ARM_fp, 
ARM_sp and ARM_cpsr, my patch incorrectly used these macros which

results in such compile errors if applied to 4.0 directly:
error: 'struct pt_regs' has no member named 'ARM_pc'
error: 'struct pt_regs' has no member named 'ARM_fp'
error: 'struct pt_regs' has no member named 'ARM_sp'
error: 'struct pt_regs' has no member named 'ARM_cpsr'

I will fix the code and do more test.



Please fix the code and actually check that you're getting sensible
callchains before sending a new version of the patch.

Thanks,

Will

.




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

[PATCH v3 0/2] arm & arm64: perf: Fix callchain parse error with

[Hou Pengyang]

For arm & arm64, when tracing with tracepoint events, the IP and cpsr 
are set to 0, preventing the perf code parsing the callchain and 
resolving the symbols correctly. 

These two patches fix this by implementing perf_arch_fetch_caller_regs
for arm and arm64, which fills several necessary register info for 
callchain unwinding and symbol resolving.

v2->v3:
 - split the original patch into two, one for arm and the other arm64;
 - change '|=' to '=' when setting cpsr. 

Hou Pengyang (2):
  arm: perf: Fix callchain parse error with kernel tracepoint events
  arm64: perf: Fix callchain parse error with kernel tracepoint events

 arch/arm/include/asm/perf_event.h   | 7 +++
 arch/arm64/include/asm/perf_event.h | 7 +++
 2 files changed, 14 insertions(+)

-- 
1.8.3.4

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

[PATCH v3 1/2] arm: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For ARM, when tracing with tracepoint events, the IP and cpsr are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.006 MB perf.data ]
 ./perf report -f
Samples: 5  of event 'sched:sched_switch', Event count (approx.): 5 
Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and cpsr.

With this patch, callchain can be parsed correctly as :

   .
-  100.00%   100.00%  ls   [kernel.kallsyms]  [k] __sched_text_start 
   + __sched_text_start 
+   20.00% 0.00%  ls   libc-2.18.so   [.] _dl_addr 
+   20.00% 0.00%  ls   libc-2.18.so   [.] write
   .

Jean Pihet found this in ARM and come up with a patch:
http://thread.gmane.org/gmane.linux.kernel/1734283/focus=1734280

This patch rewrite Jean's patch in C.

Signed-off-by: Hou Pengyang 
---
 arch/arm/include/asm/perf_event.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/perf_event.h 
b/arch/arm/include/asm/perf_event.h
index d9cf138..4f9dec4 100644
--- a/arch/arm/include/asm/perf_event.h
+++ b/arch/arm/include/asm/perf_event.h
@@ -19,4 +19,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   (regs)->ARM_pc = (__ip); \
+   (regs)->ARM_fp = (unsigned long) __builtin_frame_address(0); \
+   (regs)->ARM_sp = current_stack_pointer; \
+   (regs)->ARM_cpsr = SVC_MODE; \
+}
+
 #endif /* __ARM_PERF_EVENT_H__ */
-- 
1.8.3.4

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

[PATCH v3 2/2] arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For ARM64, when tracing with tracepoint events, the IP and pstate are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
 ./perf report -f
Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194
Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and spsr .

With this patch, callchain can be parsed correctly as follows:

 ..
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] vfs_symlink
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] follow_down
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_get
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] do_execveat_common.isra.33
-2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_send_policy_notify
 pfkey_send_policy_notify
 pfkey_get
 v9fs_vfs_rename
 page_follow_link_light
 link_path_walk
 el0_svc_naked
...

Signed-off-by: Hou Pengyang 
---
 arch/arm64/include/asm/perf_event.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/include/asm/perf_event.h 
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..cc92021 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   (regs)->ARM_pc = (__ip);\
+   (regs)->ARM_fp = (unsigned long) __builtin_frame_address(0); \
+   (regs)->ARM_sp = current_stack_pointer; \
+   (regs)->ARM_cpsr = PSR_MODE_EL1h;   \
+}
+
 #endif
-- 
1.8.3.4

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

[PATCH v3 1/2] arm: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For ARM, when tracing with tracepoint events, the IP and cpsr are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.006 MB perf.data ]
 ./perf report -f
Samples: 5  of event 'sched:sched_switch', Event count (approx.): 5 
Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and cpsr.

With this patch, callchain can be parsed correctly as :

   .
-  100.00%   100.00%  ls   [kernel.kallsyms]  [k] __sched_text_start 
   + __sched_text_start 
+   20.00% 0.00%  ls   libc-2.18.so   [.] _dl_addr 
+   20.00% 0.00%  ls   libc-2.18.so   [.] write
   .

Jean Pihet found this in ARM and come up with a patch:
http://thread.gmane.org/gmane.linux.kernel/1734283/focus=1734280

This patch rewrite Jean's patch in C.

Signed-off-by: Hou Pengyang 
---
 arch/arm/include/asm/perf_event.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/perf_event.h 
b/arch/arm/include/asm/perf_event.h
index d9cf138..4f9dec4 100644
--- a/arch/arm/include/asm/perf_event.h
+++ b/arch/arm/include/asm/perf_event.h
@@ -19,4 +19,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   (regs)->ARM_pc = (__ip); \
+   (regs)->ARM_fp = (unsigned long) __builtin_frame_address(0); \
+   (regs)->ARM_sp = current_stack_pointer; \
+   (regs)->ARM_cpsr = SVC_MODE; \
+}
+
 #endif /* __ARM_PERF_EVENT_H__ */
-- 
1.8.3.4

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

[PATCH v3 2/2] arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For ARM64, when tracing with tracepoint events, the IP and pstate are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
 ./perf report -f
Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194
Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and spsr .

With this patch, callchain can be parsed correctly as follows:

 ..
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] vfs_symlink
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] follow_down
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_get
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] do_execveat_common.isra.33
-2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_send_policy_notify
 pfkey_send_policy_notify
 pfkey_get
 v9fs_vfs_rename
 page_follow_link_light
 link_path_walk
 el0_svc_naked
...

Signed-off-by: Hou Pengyang 
---
 arch/arm64/include/asm/perf_event.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/include/asm/perf_event.h 
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..cc92021 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   (regs)->ARM_pc = (__ip);\
+   (regs)->ARM_fp = (unsigned long) __builtin_frame_address(0); \
+   (regs)->ARM_sp = current_stack_pointer; \
+   (regs)->ARM_cpsr = PSR_MODE_EL1h;   \
+}
+
 #endif
-- 
1.8.3.4

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

[PATCH v3 0/2] arm & arm64: perf: Fix callchain parse error with

[Hou Pengyang]

For arm & arm64, when tracing with tracepoint events, the IP and cpsr 
are set to 0, preventing the perf code parsing the callchain and 
resolving the symbols correctly. 

These two patches fix this by implementing perf_arch_fetch_caller_regs
for arm and arm64, which fills several necessary register info for 
callchain unwinding and symbol resolving.

v2->v3:
 - split the original patch into two, one for arm and the other arm64;
 - change '|=' to '=' when setting cpsr. 

Hou Pengyang (2):
  arm: perf: Fix callchain parse error with kernel tracepoint events
  arm64: perf: Fix callchain parse error with kernel tracepoint events

 arch/arm/include/asm/perf_event.h   | 7 +++
 arch/arm64/include/asm/perf_event.h | 7 +++
 2 files changed, 14 insertions(+)

-- 
1.8.3.4

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

[PATCH v3 1/2] arm: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For ARM, when tracing with tracepoint events, the IP and cpsr are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.006 MB perf.data ]
 ./perf report -f
Samples: 5  of event 'sched:sched_switch', Event count (approx.): 5 
Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and cpsr.

With this patch, callchain can be parsed correctly as :

   .
-  100.00%   100.00%  ls   [kernel.kallsyms]  [k] __sched_text_start 
   + __sched_text_start 
+   20.00% 0.00%  ls   libc-2.18.so   [.] _dl_addr 
+   20.00% 0.00%  ls   libc-2.18.so   [.] write
   .

Jean Pihet found this in ARM and come up with a patch:
http://thread.gmane.org/gmane.linux.kernel/1734283/focus=1734280

This patch rewrite Jean's patch in C.

Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
 arch/arm/include/asm/perf_event.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/perf_event.h 
b/arch/arm/include/asm/perf_event.h
index d9cf138..4f9dec4 100644
--- a/arch/arm/include/asm/perf_event.h
+++ b/arch/arm/include/asm/perf_event.h
@@ -19,4 +19,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   (regs)-ARM_pc = (__ip); \
+   (regs)-ARM_fp = (unsigned long) __builtin_frame_address(0); \
+   (regs)-ARM_sp = current_stack_pointer; \
+   (regs)-ARM_cpsr = SVC_MODE; \
+}
+
 #endif /* __ARM_PERF_EVENT_H__ */
-- 
1.8.3.4

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

[PATCH v3 1/2] arm: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For ARM, when tracing with tracepoint events, the IP and cpsr are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.006 MB perf.data ]
 ./perf report -f
Samples: 5  of event 'sched:sched_switch', Event count (approx.): 5 
Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and cpsr.

With this patch, callchain can be parsed correctly as :

   .
-  100.00%   100.00%  ls   [kernel.kallsyms]  [k] __sched_text_start 
   + __sched_text_start 
+   20.00% 0.00%  ls   libc-2.18.so   [.] _dl_addr 
+   20.00% 0.00%  ls   libc-2.18.so   [.] write
   .

Jean Pihet found this in ARM and come up with a patch:
http://thread.gmane.org/gmane.linux.kernel/1734283/focus=1734280

This patch rewrite Jean's patch in C.

Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
 arch/arm/include/asm/perf_event.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/perf_event.h 
b/arch/arm/include/asm/perf_event.h
index d9cf138..4f9dec4 100644
--- a/arch/arm/include/asm/perf_event.h
+++ b/arch/arm/include/asm/perf_event.h
@@ -19,4 +19,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   (regs)-ARM_pc = (__ip); \
+   (regs)-ARM_fp = (unsigned long) __builtin_frame_address(0); \
+   (regs)-ARM_sp = current_stack_pointer; \
+   (regs)-ARM_cpsr = SVC_MODE; \
+}
+
 #endif /* __ARM_PERF_EVENT_H__ */
-- 
1.8.3.4

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

[PATCH v3 2/2] arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For ARM64, when tracing with tracepoint events, the IP and pstate are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
 ./perf report -f
Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194
Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and spsr .

With this patch, callchain can be parsed correctly as follows:

 ..
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] vfs_symlink
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] follow_down
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_get
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] do_execveat_common.isra.33
-2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_send_policy_notify
 pfkey_send_policy_notify
 pfkey_get
 v9fs_vfs_rename
 page_follow_link_light
 link_path_walk
 el0_svc_naked
...

Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
 arch/arm64/include/asm/perf_event.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/include/asm/perf_event.h 
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..cc92021 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   (regs)-ARM_pc = (__ip);\
+   (regs)-ARM_fp = (unsigned long) __builtin_frame_address(0); \
+   (regs)-ARM_sp = current_stack_pointer; \
+   (regs)-ARM_cpsr = PSR_MODE_EL1h;   \
+}
+
 #endif
-- 
1.8.3.4

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

[PATCH v3 2/2] arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For ARM64, when tracing with tracepoint events, the IP and pstate are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
 ./perf report -f
Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194
Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and spsr .

With this patch, callchain can be parsed correctly as follows:

 ..
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] vfs_symlink
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] follow_down
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_get
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] do_execveat_common.isra.33
-2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_send_policy_notify
 pfkey_send_policy_notify
 pfkey_get
 v9fs_vfs_rename
 page_follow_link_light
 link_path_walk
 el0_svc_naked
...

Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
 arch/arm64/include/asm/perf_event.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/include/asm/perf_event.h 
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..cc92021 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   (regs)-ARM_pc = (__ip);\
+   (regs)-ARM_fp = (unsigned long) __builtin_frame_address(0); \
+   (regs)-ARM_sp = current_stack_pointer; \
+   (regs)-ARM_cpsr = PSR_MODE_EL1h;   \
+}
+
 #endif
-- 
1.8.3.4

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

[PATCH v3 0/2] arm arm64: perf: Fix callchain parse error with

[Hou Pengyang]

For arm  arm64, when tracing with tracepoint events, the IP and cpsr 
are set to 0, preventing the perf code parsing the callchain and 
resolving the symbols correctly. 

These two patches fix this by implementing perf_arch_fetch_caller_regs
for arm and arm64, which fills several necessary register info for 
callchain unwinding and symbol resolving.

v2-v3:
 - split the original patch into two, one for arm and the other arm64;
 - change '|=' to '=' when setting cpsr. 

Hou Pengyang (2):
  arm: perf: Fix callchain parse error with kernel tracepoint events
  arm64: perf: Fix callchain parse error with kernel tracepoint events

 arch/arm/include/asm/perf_event.h   | 7 +++
 arch/arm64/include/asm/perf_event.h | 7 +++
 2 files changed, 14 insertions(+)

-- 
1.8.3.4

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

[PATCH v3 0/2] arm arm64: perf: Fix callchain parse error with

[Hou Pengyang]

For arm  arm64, when tracing with tracepoint events, the IP and cpsr 
are set to 0, preventing the perf code parsing the callchain and 
resolving the symbols correctly. 

These two patches fix this by implementing perf_arch_fetch_caller_regs
for arm and arm64, which fills several necessary register info for 
callchain unwinding and symbol resolving.

v2-v3:
 - split the original patch into two, one for arm and the other arm64;
 - change '|=' to '=' when setting cpsr. 

Hou Pengyang (2):
  arm: perf: Fix callchain parse error with kernel tracepoint events
  arm64: perf: Fix callchain parse error with kernel tracepoint events

 arch/arm/include/asm/perf_event.h   | 7 +++
 arch/arm64/include/asm/perf_event.h | 7 +++
 2 files changed, 14 insertions(+)

-- 
1.8.3.4

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

[PATCH v2] arm & arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For ARM & ARM64, when tracing with tracepoint events, the IP and cpsr are 
set to 0, preventing the perf code parsing the callchain and resolving the 
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
 ./perf report -f
Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194 
Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and psr .

With this patch, callchain can be parsed correctly as follows:

 ..
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] vfs_symlink
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] follow_down
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_get
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] do_execveat_common.isra.33
-2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_send_policy_notify
 pfkey_send_policy_notify
 pfkey_get
 v9fs_vfs_rename
 page_follow_link_light
 link_path_walk
 el0_svc_naked
...

Jean Pihet found this in ARM and come up with a patch:
http://thread.gmane.org/gmane.linux.kernel/1734283/focus=1734280

Signed-off-by: Hou Pengyang 
---
 arch/arm/include/asm/perf_event.h   | 7 +++
 arch/arm64/include/asm/perf_event.h | 7 +++
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/include/asm/perf_event.h 
b/arch/arm/include/asm/perf_event.h
index d9cf138..17705e2b 100644
--- a/arch/arm/include/asm/perf_event.h
+++ b/arch/arm/include/asm/perf_event.h
@@ -19,4 +19,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+(regs)->ARM_pc = (__ip); \
+(regs)->ARM_fp = (unsigned long) __builtin_frame_address(0); \
+(regs)->ARM_sp = current_stack_pointer; \
+(regs)->ARM_cpsr |= SYSTEM_MODE; \
+}
+
 #endif /* __ARM_PERF_EVENT_H__ */
diff --git a/arch/arm64/include/asm/perf_event.h 
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..e6911a4 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+(regs)->ARM_pc = (__ip);\
+(regs)->ARM_fp = (unsigned long) __builtin_frame_address(0); \
+(regs)->ARM_sp = current_stack_pointer; \
+(regs)->ARM_cpsr |= PSR_MODE_EL1h; \
+}
+
 #endif
-- 
1.8.5.2

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

Re: [PATCH] arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

On 2015/4/29 18:12, Will Deacon wrote:

Hello,

On Tue, Apr 28, 2015 at 02:20:48PM +0100, Hou Pengyang wrote:

For ARM64, when tracing with tracepoint events, the IP and cpsr are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

  ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
  ./perf report -f
 Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194
 Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and psr .

With this patch, callchain can be parsed correctly as follows:

  ..
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] vfs_symlink
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] follow_down
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_get
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] do_execveat_common.isra.33
-2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_send_policy_notify
  pfkey_send_policy_notify
  pfkey_get
  v9fs_vfs_rename
  page_follow_link_light
  link_path_walk
  el0_svc_naked
 ...

For tracepoint event, stack parsing also doesn't work well for ARM. Jean Pihet
comed up a patch:
http://thread.gmane.org/gmane.linux.kernel/1734283/focus=1734280


Any chance you could revive that series too, please? I'd like to update both
arm and arm64 together, since we're currently working at merging the two
perf backends and introducing discrepencies is going to delay that even
longer.


  hi, Will, following your suggestion, I have rewrite the patch in four
lines of C, which would be shown in patch v2. what's more, both arm and
arm64 are offered. code between arm and arm64 are almost the same, so it
would be convenient to merge them together.

BTW, you're working on merging perf backends of arm and arm64, by which
git address can I follow the progress? thanks.

Hou.


Signed-off-by: Hou Pengyang 
---
  arch/arm64/include/asm/perf_event.h | 16 
  1 file changed, 16 insertions(+)

diff --git a/arch/arm64/include/asm/perf_event.h 
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..16a074f 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,20 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
  #define perf_misc_flags(regs) perf_misc_flags(regs)
  #endif

+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   unsigned long sp;   \
+   __asm__ ("mov %[sp], sp\n" : [sp] "=r" (sp)); \
+   (regs)->pc = (__ip);\
+   __asm__ (  \
+   "str %[sp],  %[_arm64_sp]  \n\t"\
+   "str x29, %[_arm64_fp]  \n\t"\
+   "mrs %[_arm64_cpsr], spsr_el1 \n\t" \
+   : [_arm64_sp] "=m" (regs->sp),  \
+ [_arm64_fp] "=m" (regs->regs[29]),  \
+ [_arm64_cpsr] "=r" (regs->pstate) \


Does this really all need to be in assembly code? Ideally we'd use something
like __builtin_stack_pointer and __builtin_frame_pointer. That just leaves
the CPSR, but given that it's (a) only used for user_mode_regs tests and (b)
this macro is only used by ftrace, then we just set it to a static value
indicating that we're at EL1.

So I *think* we should be able to write this as three lines of C.

Will

.




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

[PATCH v2] arm arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For ARM  ARM64, when tracing with tracepoint events, the IP and cpsr are 
set to 0, preventing the perf code parsing the callchain and resolving the 
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
 ./perf report -f
Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194 
Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and psr .

With this patch, callchain can be parsed correctly as follows:

 ..
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] vfs_symlink
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] follow_down
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_get
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] do_execveat_common.isra.33
-2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_send_policy_notify
 pfkey_send_policy_notify
 pfkey_get
 v9fs_vfs_rename
 page_follow_link_light
 link_path_walk
 el0_svc_naked
...

Jean Pihet found this in ARM and come up with a patch:
http://thread.gmane.org/gmane.linux.kernel/1734283/focus=1734280

Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
 arch/arm/include/asm/perf_event.h   | 7 +++
 arch/arm64/include/asm/perf_event.h | 7 +++
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/include/asm/perf_event.h 
b/arch/arm/include/asm/perf_event.h
index d9cf138..17705e2b 100644
--- a/arch/arm/include/asm/perf_event.h
+++ b/arch/arm/include/asm/perf_event.h
@@ -19,4 +19,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+(regs)-ARM_pc = (__ip); \
+(regs)-ARM_fp = (unsigned long) __builtin_frame_address(0); \
+(regs)-ARM_sp = current_stack_pointer; \
+(regs)-ARM_cpsr |= SYSTEM_MODE; \
+}
+
 #endif /* __ARM_PERF_EVENT_H__ */
diff --git a/arch/arm64/include/asm/perf_event.h 
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..e6911a4 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,11 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+(regs)-ARM_pc = (__ip);\
+(regs)-ARM_fp = (unsigned long) __builtin_frame_address(0); \
+(regs)-ARM_sp = current_stack_pointer; \
+(regs)-ARM_cpsr |= PSR_MODE_EL1h; \
+}
+
 #endif
-- 
1.8.5.2

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

Re: [PATCH] arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

On 2015/4/29 18:12, Will Deacon wrote:

Hello,

On Tue, Apr 28, 2015 at 02:20:48PM +0100, Hou Pengyang wrote:

For ARM64, when tracing with tracepoint events, the IP and cpsr are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

  ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
  ./perf report -f
 Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194
 Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and psr .

With this patch, callchain can be parsed correctly as follows:

  ..
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] vfs_symlink
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] follow_down
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_get
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] do_execveat_common.isra.33
-2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_send_policy_notify
  pfkey_send_policy_notify
  pfkey_get
  v9fs_vfs_rename
  page_follow_link_light
  link_path_walk
  el0_svc_naked
 ...

For tracepoint event, stack parsing also doesn't work well for ARM. Jean Pihet
comed up a patch:
http://thread.gmane.org/gmane.linux.kernel/1734283/focus=1734280


Any chance you could revive that series too, please? I'd like to update both
arm and arm64 together, since we're currently working at merging the two
perf backends and introducing discrepencies is going to delay that even
longer.


  hi, Will, following your suggestion, I have rewrite the patch in four
lines of C, which would be shown in patch v2. what's more, both arm and
arm64 are offered. code between arm and arm64 are almost the same, so it
would be convenient to merge them together.

BTW, you're working on merging perf backends of arm and arm64, by which
git address can I follow the progress? thanks.

Hou.


Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
  arch/arm64/include/asm/perf_event.h | 16 
  1 file changed, 16 insertions(+)

diff --git a/arch/arm64/include/asm/perf_event.h 
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..16a074f 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,20 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
  #define perf_misc_flags(regs) perf_misc_flags(regs)
  #endif

+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   unsigned long sp;   \
+   __asm__ (mov %[sp], sp\n : [sp] =r (sp)); \
+   (regs)-pc = (__ip);\
+   __asm__ (  \
+   str %[sp],  %[_arm64_sp]  \n\t\
+   str x29, %[_arm64_fp]  \n\t\
+   mrs %[_arm64_cpsr], spsr_el1 \n\t \
+   : [_arm64_sp] =m (regs-sp),  \
+ [_arm64_fp] =m (regs-regs[29]),  \
+ [_arm64_cpsr] =r (regs-pstate) \


Does this really all need to be in assembly code? Ideally we'd use something
like __builtin_stack_pointer and __builtin_frame_pointer. That just leaves
the CPSR, but given that it's (a) only used for user_mode_regs tests and (b)
this macro is only used by ftrace, then we just set it to a static value
indicating that we're at EL1.

So I *think* we should be able to write this as three lines of C.

Will

.




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

Re: [PATCH] arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

On 2015/4/29 18:12, Will Deacon wrote:

Hello,

On Tue, Apr 28, 2015 at 02:20:48PM +0100, Hou Pengyang wrote:

For ARM64, when tracing with tracepoint events, the IP and cpsr are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

  ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
  ./perf report -f
 Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194
 Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and psr .

With this patch, callchain can be parsed correctly as follows:

  ..
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] vfs_symlink
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] follow_down
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_get
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] do_execveat_common.isra.33
-2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_send_policy_notify
  pfkey_send_policy_notify
  pfkey_get
  v9fs_vfs_rename
  page_follow_link_light
  link_path_walk
  el0_svc_naked
 ...

For tracepoint event, stack parsing also doesn't work well for ARM. Jean Pihet
comed up a patch:
http://thread.gmane.org/gmane.linux.kernel/1734283/focus=1734280


Any chance you could revive that series too, please? I'd like to update both
arm and arm64 together, since we're currently working at merging the two
perf backends and introducing discrepencies is going to delay that even
longer.


Signed-off-by: Hou Pengyang 
---
  arch/arm64/include/asm/perf_event.h | 16 
  1 file changed, 16 insertions(+)

diff --git a/arch/arm64/include/asm/perf_event.h 
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..16a074f 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,20 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
  #define perf_misc_flags(regs) perf_misc_flags(regs)
  #endif

+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   unsigned long sp;   \
+   __asm__ ("mov %[sp], sp\n" : [sp] "=r" (sp)); \
+   (regs)->pc = (__ip);\
+   __asm__ (  \
+   "str %[sp],  %[_arm64_sp]  \n\t"\
+   "str x29, %[_arm64_fp]  \n\t"\
+   "mrs %[_arm64_cpsr], spsr_el1 \n\t" \
+   : [_arm64_sp] "=m" (regs->sp),  \
+ [_arm64_fp] "=m" (regs->regs[29]),  \
+ [_arm64_cpsr] "=r" (regs->pstate) \


Does this really all need to be in assembly code? Ideally we'd use something
like __builtin_stack_pointer and __builtin_frame_pointer. That just leaves
the CPSR, but given that it's (a) only used for user_mode_regs tests and (b)
this macro is only used by ftrace, then we just set it to a static value
indicating that we're at EL1.

So I *think* we should be able to write this as three lines of C.

Hi, will, as you said, we can get fp by __builtin_frame_address() and 
pstate by setting it to a static value. However, for sp, there isn't a 
gcc builtin fuction like __builtin_stack_pointer, so assembly code is 
needed. What's more, if CONFIG_FRAME_POINTER is close, can fp be got by 
__builtin_frame_address()?



Will

.




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

Re: [PATCH] arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

On 2015/4/29 18:12, Will Deacon wrote:

Hello,

On Tue, Apr 28, 2015 at 02:20:48PM +0100, Hou Pengyang wrote:

For ARM64, when tracing with tracepoint events, the IP and cpsr are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

  ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
  ./perf report -f
 Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194
 Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and psr .

With this patch, callchain can be parsed correctly as follows:

  ..
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] vfs_symlink
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] follow_down
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_get
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] do_execveat_common.isra.33
-2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_send_policy_notify
  pfkey_send_policy_notify
  pfkey_get
  v9fs_vfs_rename
  page_follow_link_light
  link_path_walk
  el0_svc_naked
 ...

For tracepoint event, stack parsing also doesn't work well for ARM. Jean Pihet
comed up a patch:
http://thread.gmane.org/gmane.linux.kernel/1734283/focus=1734280


Any chance you could revive that series too, please? I'd like to update both
arm and arm64 together, since we're currently working at merging the two
perf backends and introducing discrepencies is going to delay that even
longer.


Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
  arch/arm64/include/asm/perf_event.h | 16 
  1 file changed, 16 insertions(+)

diff --git a/arch/arm64/include/asm/perf_event.h 
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..16a074f 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,20 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
  #define perf_misc_flags(regs) perf_misc_flags(regs)
  #endif

+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   unsigned long sp;   \
+   __asm__ (mov %[sp], sp\n : [sp] =r (sp)); \
+   (regs)-pc = (__ip);\
+   __asm__ (  \
+   str %[sp],  %[_arm64_sp]  \n\t\
+   str x29, %[_arm64_fp]  \n\t\
+   mrs %[_arm64_cpsr], spsr_el1 \n\t \
+   : [_arm64_sp] =m (regs-sp),  \
+ [_arm64_fp] =m (regs-regs[29]),  \
+ [_arm64_cpsr] =r (regs-pstate) \


Does this really all need to be in assembly code? Ideally we'd use something
like __builtin_stack_pointer and __builtin_frame_pointer. That just leaves
the CPSR, but given that it's (a) only used for user_mode_regs tests and (b)
this macro is only used by ftrace, then we just set it to a static value
indicating that we're at EL1.

So I *think* we should be able to write this as three lines of C.

Hi, will, as you said, we can get fp by __builtin_frame_address() and 
pstate by setting it to a static value. However, for sp, there isn't a 
gcc builtin fuction like __builtin_stack_pointer, so assembly code is 
needed. What's more, if CONFIG_FRAME_POINTER is close, can fp be got by 
__builtin_frame_address()?



Will

.




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

[PATCH] arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For ARM64, when tracing with tracepoint events, the IP and cpsr are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
 ./perf report -f
Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194
Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and psr .

With this patch, callchain can be parsed correctly as follows:

 ..
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] vfs_symlink
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] follow_down
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_get
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] do_execveat_common.isra.33
-2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_send_policy_notify
 pfkey_send_policy_notify
 pfkey_get
 v9fs_vfs_rename
 page_follow_link_light
 link_path_walk
 el0_svc_naked
...

For tracepoint event, stack parsing also doesn't work well for ARM. Jean Pihet
comed up a patch:
http://thread.gmane.org/gmane.linux.kernel/1734283/focus=1734280

Signed-off-by: Hou Pengyang 
---
 arch/arm64/include/asm/perf_event.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/include/asm/perf_event.h 
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..16a074f 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,20 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   unsigned long sp;   \
+   __asm__ ("mov %[sp], sp\n" : [sp] "=r" (sp)); \
+   (regs)->pc = (__ip);\
+   __asm__ (  \
+   "str %[sp],  %[_arm64_sp]  \n\t"\
+   "str x29, %[_arm64_fp]  \n\t"\
+   "mrs %[_arm64_cpsr], spsr_el1 \n\t" \
+   : [_arm64_sp] "=m" (regs->sp),  \
+ [_arm64_fp] "=m" (regs->regs[29]),  \
+ [_arm64_cpsr] "=r" (regs->pstate) \
+   : [sp] "r" (sp) \
+   );  \
+}
+
+
 #endif
-- 
1.8.3.4

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

[PATCH] arm64: perf: Fix callchain parse error with kernel tracepoint events

[Hou Pengyang]

For ARM64, when tracing with tracepoint events, the IP and cpsr are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
[ perf record: Captured and wrote 0.146 MB perf.data ]
 ./perf report -f
Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194
Children  SelfCommand  Shared Object Symbol
100.00%   100.00%  ls   [unknown] [.] 

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and psr .

With this patch, callchain can be parsed correctly as follows:

 ..
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] vfs_symlink
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] follow_down
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_get
+2.63% 0.00%  ls   [kernel.kallsyms]  [k] do_execveat_common.isra.33
-2.63% 0.00%  ls   [kernel.kallsyms]  [k] pfkey_send_policy_notify
 pfkey_send_policy_notify
 pfkey_get
 v9fs_vfs_rename
 page_follow_link_light
 link_path_walk
 el0_svc_naked
...

For tracepoint event, stack parsing also doesn't work well for ARM. Jean Pihet
comed up a patch:
http://thread.gmane.org/gmane.linux.kernel/1734283/focus=1734280

Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
 arch/arm64/include/asm/perf_event.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/include/asm/perf_event.h 
b/arch/arm64/include/asm/perf_event.h
index d26d1d5..16a074f 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -24,4 +24,20 @@ extern unsigned long perf_misc_flags(struct pt_regs *regs);
 #define perf_misc_flags(regs)  perf_misc_flags(regs)
 #endif
 
+#define perf_arch_fetch_caller_regs(regs, __ip) { \
+   unsigned long sp;   \
+   __asm__ (mov %[sp], sp\n : [sp] =r (sp)); \
+   (regs)-pc = (__ip);\
+   __asm__ (  \
+   str %[sp],  %[_arm64_sp]  \n\t\
+   str x29, %[_arm64_fp]  \n\t\
+   mrs %[_arm64_cpsr], spsr_el1 \n\t \
+   : [_arm64_sp] =m (regs-sp),  \
+ [_arm64_fp] =m (regs-regs[29]),  \
+ [_arm64_cpsr] =r (regs-pstate) \
+   : [sp] r (sp) \
+   );  \
+}
+
+
 #endif
-- 
1.8.3.4

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

[PATCH] ftrace: Fix comments about trace/ftrace.h

[Hou Pengyang]

commit f42c85e74faa422cf0bc747ed808681145448f88 moved tracepoint's ftrace 
creation into include/trace/ftrace.h and trace/define_trach.h was deleted 
as a result. However some comment info does not adapt to the change, which 
is such a misguiding when reading related code. 

This patch fix this by moving trace/trace_events.h to ,
since tracepoint headers have already been moved to tarce/events/.

Signed-off-by: Hou Pengyang 
---
 include/trace/ftrace.h | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 41bf65f..44f9a98 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -1,7 +1,8 @@
 /*
  * Stage 1 of the trace events.
  *
- * Override the macros in  to include the following:
+ * Override the macros in the event tracepoint header 
+ * to include the following:
  *
  * struct ftrace_raw_ {
  * struct trace_entry  ent;
@@ -170,7 +171,8 @@
 /*
  * Stage 3 of the trace events.
  *
- * Override the macros in  to include the following:
+ * Override the macros in the event tracepoint header 
+ * to include the following:
  *
  * enum print_line_t
  * ftrace_raw_output_(struct trace_iterator *iter, int flags)
@@ -479,7 +481,8 @@ static inline notrace int ftrace_get_offsets_##call(
\
 /*
  * Stage 4 of the trace events.
  *
- * Override the macros in  to include the following:
+ * Override the macros in the event tracepoint header 
+ * to include the following:
  *
  * For those macros defined with TRACE_EVENT:
  *
-- 
1.8.3.4

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

[PATCH] ftrace: Fix comments about trace/ftrace.h

[Hou Pengyang]

commit f42c85e74faa422cf0bc747ed808681145448f88 moved tracepoint's ftrace 
creation into include/trace/ftrace.h and trace/define_trach.h was deleted 
as a result. However some comment info does not adapt to the change, which 
is such a misguiding when reading related code. 

This patch fix this by moving trace/trace_events.h to trace/events/XXX.h,
since tracepoint headers have already been moved to tarce/events/.

Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
 include/trace/ftrace.h | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 41bf65f..44f9a98 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -1,7 +1,8 @@
 /*
  * Stage 1 of the trace events.
  *
- * Override the macros in trace/trace_events.h to include the following:
+ * Override the macros in the event tracepoint header trace/events/XXX.h
+ * to include the following:
  *
  * struct ftrace_raw_call {
  * struct trace_entry  ent;
@@ -170,7 +171,8 @@
 /*
  * Stage 3 of the trace events.
  *
- * Override the macros in trace/trace_events.h to include the following:
+ * Override the macros in the event tracepoint header trace/events/XXX.h
+ * to include the following:
  *
  * enum print_line_t
  * ftrace_raw_output_call(struct trace_iterator *iter, int flags)
@@ -479,7 +481,8 @@ static inline notrace int ftrace_get_offsets_##call(
\
 /*
  * Stage 4 of the trace events.
  *
- * Override the macros in trace/trace_events.h to include the following:
+ * Override the macros in the event tracepoint header trace/events/XXX.h
+ * to include the following:
  *
  * For those macros defined with TRACE_EVENT:
  *
-- 
1.8.3.4

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

Re: [PATCH] ftrace: Fix comments about trace/ftrace.h

[Hou Pengyang]

On 2015/3/2 22:10, Steven Rostedt wrote:

On Mon, 2 Mar 2015 14:28:54 +
Hou Pengyang  wrote:


commit f42c85e74faa422cf0bc747ed808681145448f88 moves tracepoint's ftrace
creation into include/trace/ftrace.h and trace/define_trach.h is deleted


You mean event_trace.h is deleted.
yes, commit f42c85e74faa422cf0bc747ed808681145448f88 refactored code, 
and event_trace.h was deleted.



as a result. However some comment info does not adapt to the change, which
I think is such a misguiding when reading related code.

This patch fix this comment by moving trace/trace_events.h to TRACE_INCLUDE
(TRACE_INCLUDE_FILE), the macro TRACE_INCLUDE(TRACE_INCLUDE_FILE) is defined
in trace/define_trace.h

Signed-off-by: Hou Pengyang 
---
  include/trace/ftrace.h | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 41bf65f..cb78a8b 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -1,7 +1,8 @@
  /*
   * Stage 1 of the trace events.
   *
- * Override the macros in  to include the following:
+ * Override the macros in TRACE_INCLUDE(TRACE_INCLUDE_FILE) to


I agree that the comment needs updating, but not to this.
TRACE_INCLUDE(TRACE_INCLUDE_FILE) is not very descriptive. Because
nobody understand exactly what that is. Do you?

Change it to:

   Override the macros in the event tracepoint header ...

And do that for the ones below too. This is more descriptive than just
describing what the code is literally doing.

-- Steve

To be more descriptive, how about "Override the macros in the event 
tracepoint header  ..." ? since, tracepoint headers 
have already been moved to trace/events/ .



+ * include the following:
   *
   * struct ftrace_raw_ {
   *struct trace_entry  ent;
@@ -170,7 +171,8 @@
  /*
   * Stage 3 of the trace events.
   *
- * Override the macros in  to include the following:
+ * Override the macros in TRACE_INCLUDE(TRACE_INCLUDE_FILE) to
+ * include the following:
   *
   * enum print_line_t
   * ftrace_raw_output_(struct trace_iterator *iter, int flags)
@@ -479,7 +481,8 @@ static inline notrace int ftrace_get_offsets_##call(
\
  /*
   * Stage 4 of the trace events.
   *
- * Override the macros in  to include the following:
+ * Override the macros in TRACE_INCLUDE(TRACE_INCLUDE_FILE) to
+ * include the following:
   *
   * For those macros defined with TRACE_EVENT:
   *



.




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

Re: [PATCH] ftrace: Fix comments about trace/ftrace.h

[Hou Pengyang]

On 2015/3/2 22:10, Steven Rostedt wrote:

On Mon, 2 Mar 2015 14:28:54 +
Hou Pengyang houpengy...@huawei.com wrote:


commit f42c85e74faa422cf0bc747ed808681145448f88 moves tracepoint's ftrace
creation into include/trace/ftrace.h and trace/define_trach.h is deleted


You mean event_trace.h is deleted.
yes, commit f42c85e74faa422cf0bc747ed808681145448f88 refactored code, 
and event_trace.h was deleted.



as a result. However some comment info does not adapt to the change, which
I think is such a misguiding when reading related code.

This patch fix this comment by moving trace/trace_events.h to TRACE_INCLUDE
(TRACE_INCLUDE_FILE), the macro TRACE_INCLUDE(TRACE_INCLUDE_FILE) is defined
in trace/define_trace.h

Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
  include/trace/ftrace.h | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 41bf65f..cb78a8b 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -1,7 +1,8 @@
  /*
   * Stage 1 of the trace events.
   *
- * Override the macros in trace/trace_events.h to include the following:
+ * Override the macros in TRACE_INCLUDE(TRACE_INCLUDE_FILE) to


I agree that the comment needs updating, but not to this.
TRACE_INCLUDE(TRACE_INCLUDE_FILE) is not very descriptive. Because
nobody understand exactly what that is. Do you?

Change it to:

   Override the macros in the event tracepoint header ...

And do that for the ones below too. This is more descriptive than just
describing what the code is literally doing.

-- Steve

To be more descriptive, how about Override the macros in the event 
tracepoint header trace/events/XXX.h ... ? since, tracepoint headers 
have already been moved to trace/events/ .



+ * include the following:
   *
   * struct ftrace_raw_call {
   *struct trace_entry  ent;
@@ -170,7 +171,8 @@
  /*
   * Stage 3 of the trace events.
   *
- * Override the macros in trace/trace_events.h to include the following:
+ * Override the macros in TRACE_INCLUDE(TRACE_INCLUDE_FILE) to
+ * include the following:
   *
   * enum print_line_t
   * ftrace_raw_output_call(struct trace_iterator *iter, int flags)
@@ -479,7 +481,8 @@ static inline notrace int ftrace_get_offsets_##call(
\
  /*
   * Stage 4 of the trace events.
   *
- * Override the macros in trace/trace_events.h to include the following:
+ * Override the macros in TRACE_INCLUDE(TRACE_INCLUDE_FILE) to
+ * include the following:
   *
   * For those macros defined with TRACE_EVENT:
   *



.




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

[PATCH] ftrace: Fix comments about trace/ftrace.h

[Hou Pengyang]

commit f42c85e74faa422cf0bc747ed808681145448f88 moves tracepoint's ftrace 
creation into include/trace/ftrace.h and trace/define_trach.h is deleted 
as a result. However some comment info does not adapt to the change, which 
I think is such a misguiding when reading related code. 

This patch fix this comment by moving trace/trace_events.h to TRACE_INCLUDE
(TRACE_INCLUDE_FILE), the macro TRACE_INCLUDE(TRACE_INCLUDE_FILE) is defined
in trace/define_trace.h

Signed-off-by: Hou Pengyang 
---
 include/trace/ftrace.h | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 41bf65f..cb78a8b 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -1,7 +1,8 @@
 /*
  * Stage 1 of the trace events.
  *
- * Override the macros in  to include the following:
+ * Override the macros in TRACE_INCLUDE(TRACE_INCLUDE_FILE) to 
+ * include the following:
  *
  * struct ftrace_raw_ {
  * struct trace_entry  ent;
@@ -170,7 +171,8 @@
 /*
  * Stage 3 of the trace events.
  *
- * Override the macros in  to include the following:
+ * Override the macros in TRACE_INCLUDE(TRACE_INCLUDE_FILE) to 
+ * include the following:
  *
  * enum print_line_t
  * ftrace_raw_output_(struct trace_iterator *iter, int flags)
@@ -479,7 +481,8 @@ static inline notrace int ftrace_get_offsets_##call(
\
 /*
  * Stage 4 of the trace events.
  *
- * Override the macros in  to include the following:
+ * Override the macros in TRACE_INCLUDE(TRACE_INCLUDE_FILE) to 
+ * include the following:
  *
  * For those macros defined with TRACE_EVENT:
  *
-- 
1.8.3.4

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

[PATCH] ftrace: Fix comments about trace/ftrace.h

[Hou Pengyang]

commit f42c85e74faa422cf0bc747ed808681145448f88 moves tracepoint's ftrace 
creation into include/trace/ftrace.h and trace/define_trach.h is deleted 
as a result. However some comment info does not adapt to the change, which 
I think is such a misguiding when reading related code. 

This patch fix this comment by moving trace/trace_events.h to TRACE_INCLUDE
(TRACE_INCLUDE_FILE), the macro TRACE_INCLUDE(TRACE_INCLUDE_FILE) is defined
in trace/define_trace.h

Signed-off-by: Hou Pengyang houpengy...@huawei.com
---
 include/trace/ftrace.h | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 41bf65f..cb78a8b 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -1,7 +1,8 @@
 /*
  * Stage 1 of the trace events.
  *
- * Override the macros in trace/trace_events.h to include the following:
+ * Override the macros in TRACE_INCLUDE(TRACE_INCLUDE_FILE) to 
+ * include the following:
  *
  * struct ftrace_raw_call {
  * struct trace_entry  ent;
@@ -170,7 +171,8 @@
 /*
  * Stage 3 of the trace events.
  *
- * Override the macros in trace/trace_events.h to include the following:
+ * Override the macros in TRACE_INCLUDE(TRACE_INCLUDE_FILE) to 
+ * include the following:
  *
  * enum print_line_t
  * ftrace_raw_output_call(struct trace_iterator *iter, int flags)
@@ -479,7 +481,8 @@ static inline notrace int ftrace_get_offsets_##call(
\
 /*
  * Stage 4 of the trace events.
  *
- * Override the macros in trace/trace_events.h to include the following:
+ * Override the macros in TRACE_INCLUDE(TRACE_INCLUDE_FILE) to 
+ * include the following:
  *
  * For those macros defined with TRACE_EVENT:
  *
-- 
1.8.3.4

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