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@xxxxxxx>
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
