Re: [PATCH v3] mm: vmscan: rework lru_shrink and write_folio tracepoints

quoted hunk

-     TP_printk("page=%p pfn=0x%lx flags=%s",
-             pfn_to_page(__entry->pfn),
-             __entry->pfn,
-             show_reclaim_flags(__entry->reclaim_flags))
+     TP_printk("folio=%p lru=%s",
+             __entry->folio,
+             __print_symbolic(__entry->lru, LRU_NAMES))
 );

Why is it useful to print out the folio pointer?  Printing out the PFN made more sense to me.

Tracking a folio pointer gives developers an immediate, unambiguous view of which memory object is being scanned or reclaimed
and where it lives in the LRU lists, rather than dealing with page frame number.
As you mentioned in patch v1: https://lore.kernel.org/all/afdBCWopkfF2ow-Z@casper.infradead.org/ (local),
the original code chooses to save the pfn, and then forcibly converts it back to a pointer via pfn_to_page() during printing.
This is an unnecessary indirection that adds code complexity without providing any extra benefit.
Printing out the PFN surely provides a direct view of the physical address information, if pfn is needed, just print it by folio_pfn()
as showed below:
TRACE_EVENT(mm_vmscan_write_folio,

        TP_PROTO(struct folio *folio),

        TP_ARGS(folio),

        TP_STRUCT__entry(
                __field(struct folio *, folio)
                __field(int, lru)
        ),

        TP_fast_assign(
                __entry->folio = folio;
                __entry->lru = folio_lru_list(folio);
        ),

        TP_printk("folio=%p pfn==0x%lx lru=%s",
                __entry->folio,
                folio_pfn(__entry->folio),
                __print_symbolic(__entry->lru, LRU_NAMES))
);