Re: [PATCH v2 1/2] hugetlbfs: support tracepoint

[Hongbo Li <lihongbo22@huawei.com>]

On 2024/7/5 7:34, Dave Chinner wrote:
> On Thu, Jul 04, 2024 at 10:13:22AM -0400, Steven Rostedt wrote:
>> On Thu, 4 Jul 2024 22:56:29 +1000
>> Dave Chinner <david@fromorbit.com> wrote:
>>
>>> Having to do this is additional work when writing use-once scripts
>>> that get thrown away when the tracepoint output analysis is done
>>> is painful, and it's completely unnecessary if the tracepoint output
>>> is completely space separated from the start.
>>
>> If you are using scripts to parse the output, then you could just
>> enable the "fields" options, which will just ignore the TP_printk() and
>> print the fields in both their hex and decimal values:
>>
>>   # trace-cmd start -e filemap -O fields
>>
>> // the above fields change can also be done with:
>> //  echo 1 > /sys/kernel/tracing/options/fields
>>
>>   # trace-cmd show
>> # tracer: nop
>> #
>> # entries-in-buffer/entries-written: 8/8   #P:8
>> #
>> #                                _-----=> irqs-off/BH-disabled
>> #                               / _----=> need-resched
>> #                              | / _---=> hardirq/softirq
>> #                              || / _--=> preempt-depth
>> #                              ||| / _-=> migrate-disable
>> #                              |||| /     delay
>> #           TASK-PID     CPU#  |||||  TIMESTAMP  FUNCTION
>> #              | |         |   |||||     |         |
>>              less-2527    [004] ..... 61949.896458: mm_filemap_add_to_page_cache: pfn=0x144625 (1328677) i_ino=0x335c6 (210374) index=0x0 (0) s_dev=0xfe00003 (266338307) order=(0)
>>              less-2527    [004] d..2. 61949.896926: mm_filemap_delete_from_page_cache: pfn=0x152b07 (1387271) i_ino=0x2d73a (186170) index=0x0 (0) s_dev=0xfe00003 (266338307) order=(0)
>>       jbd2/vda3-8-268     [005] ..... 61954.461964: mm_filemap_add_to_page_cache: pfn=0x152b70 (1387376) i_ino=0xfe00003 (266338307) index=0x30bd33 (3194163) s_dev=0x3 (3) order=(0)
>>       jbd2/vda3-8-268     [005] ..... 61954.462669: mm_filemap_add_to_page_cache: pfn=0x15335b (1389403) i_ino=0xfe00003 (266338307) index=0x30bd40 (3194176) s_dev=0x3 (3) order=(0)
>>       jbd2/vda3-8-268     [005] ..... 62001.565391: mm_filemap_add_to_page_cache: pfn=0x13a996 (1288598) i_ino=0xfe00003 (266338307) index=0x30bd41 (3194177) s_dev=0x3 (3) order=(0)
>>       jbd2/vda3-8-268     [005] ..... 62001.566081: mm_filemap_add_to_page_cache: pfn=0x1446b5 (1328821) i_ino=0xfe00003 (266338307) index=0x30bd43 (3194179) s_dev=0x3 (3) order=(0)
>>              less-2530    [004] ..... 62033.182309: mm_filemap_add_to_page_cache: pfn=0x13d755 (1300309) i_ino=0x2d73a (186170) index=0x0 (0) s_dev=0xfe00003 (266338307) order=(0)
>>              less-2530    [004] d..2. 62033.182801: mm_filemap_delete_from_page_cache: pfn=0x144625 (1328677) i_ino=0x335c6 (210374) index=0x0 (0) s_dev=0xfe00003 (266338307) order=(0)
> 
> Yes, I know about that. But this just makes things harder, because
> now there are *3* different formats that have to be handled (i.e.
> now we also have to strip "()" around numbers).
Perhaps if users want to filter the format, they could enable the 
"fields" option in a unified manner. As for TP_printk(), it depends on 
how to better display the data used for debugging.

Thanks,
Hongbo
> 
> -Dave.