Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1585702 > unrolled thread

[PATCH 0/6] second round of tracepoints for DAX

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/6] second round of tracepoints for DAX Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-02-21 21:00 +0100
    [PATCH 5/6] dax: add tracepoint to dax_writeback_one() Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-02-21 21:00 +0100
    Re: [PATCH 0/6] second round of tracepoints for DAX Jan Kara <jack@suse.cz> - 2017-02-22 12:00 +0100

#1585702 — [PATCH 0/6] second round of tracepoints for DAX

This second round of DAX tracepoint patches adds tracing to the PTE fault
path (dax_iomap_pte_fault(), dax_pfn_mkwrite(), dax_load_hole(),
dax_insert_mapping()) and to the writeback path
(dax_writeback_mapping_range(), dax_writeback_one()).

The purpose of this tracing is to give us a high level view of what DAX is
doing, whether faults are being serviced by PMDs or PTEs, and by real
storage or by zero pages covering holes.

I do have some patches nearly ready which also add tracing to
grab_mapping_entry() and dax_insert_mapping_entry().  These are more
targeted at logging how we are interacting with the radix tree, how we use
empty entries for locking, whether we "downgrade" huge zero pages to
4k PTE sized allocations, etc.  In the end it seemed to me that this might
be too detailed to have as constantly present tracepoints, but if anyone
sees value in having tracepoints like this in the DAX code permanently
(Jan?), please let me know and I'll add those last two patches.

All these tracepoints were done to be consistent with the style of the XFS
tracepoints and with the existing DAX PMD tracepoints.

This series applies cleanly to the current mmots/master:

commit 35aa45ffe8d9 ("pci: test for unexpectedly disabled bridges")

and I'm hoping that it'll end up going to Linus through akpm's -mm tree.

Thanks,
- Ross

Ross Zwisler (6):
  dax: add tracepoints to dax_iomap_pte_fault()
  dax: add tracepoints to dax_pfn_mkwrite()
  dax: add tracepoints to dax_load_hole()
  dax: add tracepoints to dax_writeback_mapping_range()
  dax: add tracepoint to dax_writeback_one()
  dax: add tracepoint to dax_insert_mapping()

 fs/dax.c                      |  44 ++++++++++----
 include/trace/events/fs_dax.h | 130 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 163 insertions(+), 11 deletions(-)

-- 
2.9.3

[toc] | [next] | [standalone]

#1585703 — [PATCH 5/6] dax: add tracepoint to dax_writeback_one()

Add a tracepoint to dax_writeback_one(), following the same logging
conventions as the rest of DAX.

Here is an example range writeback which ends up flushing one PMD and one
PTE:

test-1265  [003] ....   496.615250: dax_writeback_range: dev 259:0 ino 0x1003
pgoff 0x0-0x7ffffffffffff

test-1265  [003] ....   496.616263: dax_writeback_one: dev 259:0 ino 0x1003
pgoff 0x0 pglen 0x200

test-1265  [003] ....   496.616270: dax_writeback_one: dev 259:0 ino 0x1003
pgoff 0x305 pglen 0x1

test-1265  [003] ....   496.616272: dax_writeback_range_done: dev 259:0 ino
0x1003 pgoff 0x0-0x7ffffffffffff

Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
---
 fs/dax.c                      |  1 +
 include/trace/events/fs_dax.h | 24 ++++++++++++++++++++++++
 2 files changed, 25 insertions(+)

diff --git a/fs/dax.c b/fs/dax.c
index 7ca1989..d340389 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -843,6 +843,7 @@ static int dax_writeback_one(struct block_device *bdev,
 	spin_lock_irq(&mapping->tree_lock);
 	radix_tree_tag_clear(page_tree, index, PAGECACHE_TAG_DIRTY);
 	spin_unlock_irq(&mapping->tree_lock);
+	trace_dax_writeback_one(mapping->host, index, dax.size >> PAGE_SHIFT);
  unmap:
 	dax_unmap_atomic(bdev, &dax);
 	put_locked_mapping_entry(mapping, index, entry);
diff --git a/include/trace/events/fs_dax.h b/include/trace/events/fs_dax.h
index 9afe8c8..292a471 100644
--- a/include/trace/events/fs_dax.h
+++ b/include/trace/events/fs_dax.h
@@ -226,6 +226,30 @@ DEFINE_EVENT(dax_writeback_range_class, name, \
 DEFINE_WRITEBACK_RANGE_EVENT(dax_writeback_range);
 DEFINE_WRITEBACK_RANGE_EVENT(dax_writeback_range_done);
 
+TRACE_EVENT(dax_writeback_one,
+	TP_PROTO(struct inode *inode, pgoff_t pgoff, pgoff_t pglen),
+	TP_ARGS(inode, pgoff, pglen),
+	TP_STRUCT__entry(
+		__field(unsigned long, ino)
+		__field(pgoff_t, pgoff)
+		__field(pgoff_t, pglen)
+		__field(dev_t, dev)
+	),
+	TP_fast_assign(
+		__entry->dev = inode->i_sb->s_dev;
+		__entry->ino = inode->i_ino;
+		__entry->pgoff = pgoff;
+		__entry->pglen = pglen;
+	),
+	TP_printk("dev %d:%d ino %#lx pgoff %#lx pglen %#lx",
+		MAJOR(__entry->dev),
+		MINOR(__entry->dev),
+		__entry->ino,
+		__entry->pgoff,
+		__entry->pglen
+	)
+)
+
 #endif /* _TRACE_FS_DAX_H */
 
 /* This part must be outside protection */
-- 
2.9.3

[toc] | [prev] | [next] | [standalone]

#1586063

On Tue 21-02-17 12:51:10, Ross Zwisler wrote:
> This second round of DAX tracepoint patches adds tracing to the PTE fault
> path (dax_iomap_pte_fault(), dax_pfn_mkwrite(), dax_load_hole(),
> dax_insert_mapping()) and to the writeback path
> (dax_writeback_mapping_range(), dax_writeback_one()).
> 
> The purpose of this tracing is to give us a high level view of what DAX is
> doing, whether faults are being serviced by PMDs or PTEs, and by real
> storage or by zero pages covering holes.
> 
> I do have some patches nearly ready which also add tracing to
> grab_mapping_entry() and dax_insert_mapping_entry().  These are more
> targeted at logging how we are interacting with the radix tree, how we use
> empty entries for locking, whether we "downgrade" huge zero pages to
> 4k PTE sized allocations, etc.  In the end it seemed to me that this might
> be too detailed to have as constantly present tracepoints, but if anyone
> sees value in having tracepoints like this in the DAX code permanently
> (Jan?), please let me know and I'll add those last two patches.

Yeah, for now I think it is too detailed and high-level logging is good
enough. As we will debug problems, we may find places that are useful for
more detailed tracepoints but for now what you added looks fine.

> All these tracepoints were done to be consistent with the style of the XFS
> tracepoints and with the existing DAX PMD tracepoints.
> 
> This series applies cleanly to the current mmots/master:
> 
> commit 35aa45ffe8d9 ("pci: test for unexpectedly disabled bridges")
> 
> and I'm hoping that it'll end up going to Linus through akpm's -mm tree.

I like the patches and they look fine to me. Feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web