All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org
Cc: Jan Kara <jack@suse.cz>, Matthew Wilcox <mawilcox@microsoft.com>,
	linux-nvdimm@lists.01.org, Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org
Subject: [PATCH 0/6] second round of tracepoints for DAX
Date: Tue, 21 Feb 2017 12:51:10 -0700	[thread overview]
Message-ID: <20170221195116.13278-1-ross.zwisler@linux.intel.com> (raw)

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

_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
	Jan Kara <jack@suse.cz>, Alexander Viro <viro@zeniv.linux.org.uk>,
	Dan Williams <dan.j.williams@intel.com>,
	Ingo Molnar <mingo@redhat.com>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-fsdevel@vger.kernel.org, linux-nvdimm@ml01.01.org
Subject: [PATCH 0/6] second round of tracepoints for DAX
Date: Tue, 21 Feb 2017 12:51:10 -0700	[thread overview]
Message-ID: <20170221195116.13278-1-ross.zwisler@linux.intel.com> (raw)

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

WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
	Jan Kara <jack@suse.cz>, Alexander Viro <viro@zeniv.linux.org.uk>,
	Dan Williams <dan.j.williams@intel.com>,
	Ingo Molnar <mingo@redhat.com>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-fsdevel@vger.kernel.org, linux-nvdimm@lists.01.org
Subject: [PATCH 0/6] second round of tracepoints for DAX
Date: Tue, 21 Feb 2017 12:51:10 -0700	[thread overview]
Message-ID: <20170221195116.13278-1-ross.zwisler@linux.intel.com> (raw)

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

             reply	other threads:[~2017-02-21 19:51 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-21 19:51 Ross Zwisler [this message]
2017-02-21 19:51 ` [PATCH 0/6] second round of tracepoints for DAX Ross Zwisler
2017-02-21 19:51 ` Ross Zwisler
2017-02-21 19:51 ` [PATCH 1/6] dax: add tracepoints to dax_iomap_pte_fault() Ross Zwisler
2017-02-21 19:51   ` Ross Zwisler
2017-02-21 19:51   ` Ross Zwisler
2017-02-21 19:51 ` [PATCH 2/6] dax: add tracepoints to dax_pfn_mkwrite() Ross Zwisler
2017-02-21 19:51   ` Ross Zwisler
2017-02-21 19:51   ` Ross Zwisler
2017-02-21 19:51 ` [PATCH 3/6] dax: add tracepoints to dax_load_hole() Ross Zwisler
2017-02-21 19:51   ` Ross Zwisler
2017-02-21 19:51   ` Ross Zwisler
2017-02-21 19:51 ` [PATCH 4/6] dax: add tracepoints to dax_writeback_mapping_range() Ross Zwisler
2017-02-21 19:51   ` Ross Zwisler
2017-02-21 19:51   ` Ross Zwisler
2017-02-21 19:51 ` [PATCH 5/6] dax: add tracepoint to dax_writeback_one() Ross Zwisler
2017-02-21 19:51   ` Ross Zwisler
2017-02-21 19:51   ` Ross Zwisler
2017-02-21 19:51 ` [PATCH 6/6] dax: add tracepoint to dax_insert_mapping() Ross Zwisler
2017-02-21 19:51   ` Ross Zwisler
2017-02-21 19:51   ` Ross Zwisler
2017-02-22 10:51 ` [PATCH 0/6] second round of tracepoints for DAX Jan Kara
2017-02-22 10:51   ` Jan Kara
2017-02-22 10:51   ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170221195116.13278-1-ross.zwisler@linux.intel.com \
    --to=ross.zwisler@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=mawilcox@microsoft.com \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.