perf kmem --page stat and gpf_flags translation

perf kmem --page stat and gpf_flags translation

[Michael Petlan]

Hello Steve and others,

We have found out that perf kmem --page stat sometimes fails like the
following:

# perf kmem --page stat
0x2aa28 [0x8]: failed to process type: 68 [Operation not permitted]
error during process events: -1

This seem to happen on s390x KVM machines.

When we tried to investigate for the reasons, it seems that the problem
is caused by incorrect/unexpected translation of gpf_flags for event
kmem:mm_page_alloc.

# perf script
perf   96553 [003] 100299.663963: kmem:mm_page_alloc: page=0x1a8f9 pfn=0x1a8f9 order=0 migratetype=0 gfp_flags=0x500cc2
perf   96553 [003] 100299.663995: kmem:mm_page_alloc: page=0x1bc3f pfn=0x1bc3f order=0 migratetype=0 gfp_flags=0x40cc0
perf   96553 [003] 100299.664001: kmem:mm_page_alloc: page=0x1a9d9 pfn=0x1a9d9 order=0 migratetype=0 gfp_flags=0x40cc0
perf   96553 [003] 100299.664011: kmem:mm_page_alloc: page=0x1788b pfn=0x1788b order=0 migratetype=0 gfp_flags=0x40cc0
perf   96553 [003] 100299.664023: kmem:mm_page_alloc: page=0x17993 pfn=0x17993 order=0 migratetype=0 gfp_flags=0xcc0

On another machine to be compared against, we get the gfp_flags
translated as following:

[...]
perf 1440545 [007] 37432230.091272: kmem:mm_page_alloc: page=0x10d876 pfn=0x10d876 order=0 migratetype=0 gfp_flags=GFP_HIGHUSER|__GFP_ACCOUNT
[...]

When we dig into the translation process, we get into libtraceevent (which
we have in 1.8.2 version), we get into:

     4796 static void print_str_arg(struct trace_seq *s, void *data, int size,
     4797                           struct tep_event *event, const char *format,
     4798                           int len_arg, struct tep_print_arg *arg)
     4799 {
[...]
     4876         case TEP_PRINT_FLAGS:
     4877                 val = eval_num_arg(data, size, event, arg->flags.field);
     4878                 print = 0;
B+   4879                 for (flag = arg->flags.flags; flag; flag = flag->next) {
     4880                         fval = eval_flag(flag->value);
  >  4881                         if (!val && fval < 0) {
     4882                                 print_str_to_seq(s, format, len_arg, flag->str);
     4883                                 break;
     4884                         }
     4885                         if (fval > 0 && (val & fval) == fval) {
b+   4886                                 if (print && arg->flags.delim)
     4887                                         trace_seq_puts(s, arg->flags.delim);
     4888                                 print_str_to_seq(s, format, len_arg, flag->str);
     4889                                 print = 1;
     4890                                 val &= ~fval;
     4891                         }
     4892                 }
b+   4893                 if (val) {
     4894                         if (print && arg->flags.delim)
     4895                                 trace_seq_puts(s, arg->flags.delim);
     4896                         trace_seq_printf(s, "0x%llx", val);
     4897                 }
     4898                 break;

Here in the for loop, we try to apply all the known GFP flags to the
value and if it matches, the flag name is added to the resulting string.
If it does not match (line 4885), finally a fallback solution is used
and the hex number is printed (line 4896).

The reason why it does not match any GPF flag is because the values seem
to be incorrect, so while val == 0x500cc2, the values in flags are 0 or 1:

(gdb) p *flag
$53 = {next = 0x15c3020, value = 0x15c34a0 "1", str = 0x15c2dd0 "GFP_HIGHUSER"}
(gdb) p *flag->next
$54 = {next = 0x15c3ce0, value = 0x15c3740 "1", str = 0x15c3c20 "GFP_USER"}
(gdb) p *flag->next->next
$55 = {next = 0x15c32c0, value = 0x15c2e30 "1", str = 0x15c3800 "GFP_KERNEL_ACCOUNT"}
[...]

which is obviously wrong. On the other machine the values made more sense:

(gdb) p *flag->next->next->next
$133 = {next = 0xee5630, value = 0xee57b0 "1051842", str = 0xee5930 "GFP_HIGHUSER"}
(gdb) p *flag->next->next->next->next
$134 = {next = 0xee5c90, value = 0xee5690 "1051840", str = 0xee62d0 "GFP_USER"}
(gdb) p *flag->next->next->next->next->next
$135 = {next = 0xee5990, value = 0xee5270 "4197568", str = 0xee60f0 "GFP_KERNEL_ACCOUNT"}

...

I am wondering where these values come from and where they are possibly
incorrectly set.

Any ideas?

Thanks!

Michael

Re: perf kmem --page stat and gpf_flags translation

[Steven Rostedt]

On Thu, 21 Nov 2024 14:54:25 +0100 (CET)
Michael Petlan <mpetlan@redhat.com> wrote:

> Hello Steve and others,
> 
> We have found out that perf kmem --page stat sometimes fails like the
> following:
> 
> # perf kmem --page stat
> 0x2aa28 [0x8]: failed to process type: 68 [Operation not permitted]
> error during process events: -1
> 
> This seem to happen on s390x KVM machines.
> 
> When we tried to investigate for the reasons, it seems that the problem
> is caused by incorrect/unexpected translation of gpf_flags for event
> kmem:mm_page_alloc.
> 
> # perf script
> perf   96553 [003] 100299.663963: kmem:mm_page_alloc: page=0x1a8f9 pfn=0x1a8f9 order=0 migratetype=0 gfp_flags=0x500cc2
> perf   96553 [003] 100299.663995: kmem:mm_page_alloc: page=0x1bc3f pfn=0x1bc3f order=0 migratetype=0 gfp_flags=0x40cc0
> perf   96553 [003] 100299.664001: kmem:mm_page_alloc: page=0x1a9d9 pfn=0x1a9d9 order=0 migratetype=0 gfp_flags=0x40cc0
> perf   96553 [003] 100299.664011: kmem:mm_page_alloc: page=0x1788b pfn=0x1788b order=0 migratetype=0 gfp_flags=0x40cc0
> perf   96553 [003] 100299.664023: kmem:mm_page_alloc: page=0x17993 pfn=0x17993 order=0 migratetype=0 gfp_flags=0xcc0
> 

Does the same thing happen with trace-cmd record?

 # trace-cmd record -e mm_page_alloc
[ run tests, hit Ctrl^C ]

 # trace-cmd report

?

If so, could you send the trace.dat file to me.

Thanks,

-- Steve

Re: perf kmem --page stat and gpf_flags translation

[Veronika Molnarova]

[-- Attachment #1: Type: text/plain, Size: 2114 bytes --]



On 11/21/24 16:03, Steven Rostedt wrote:
> On Thu, 21 Nov 2024 14:54:25 +0100 (CET)
> Michael Petlan <mpetlan@redhat.com> wrote:
> 
>> Hello Steve and others,
>>
>> We have found out that perf kmem --page stat sometimes fails like the
>> following:
>>
>> # perf kmem --page stat
>> 0x2aa28 [0x8]: failed to process type: 68 [Operation not permitted]
>> error during process events: -1
>>
>> This seem to happen on s390x KVM machines.
>>
>> When we tried to investigate for the reasons, it seems that the problem
>> is caused by incorrect/unexpected translation of gpf_flags for event
>> kmem:mm_page_alloc.
>>
>> # perf script
>> perf   96553 [003] 100299.663963: kmem:mm_page_alloc: page=0x1a8f9 pfn=0x1a8f9 order=0 migratetype=0 gfp_flags=0x500cc2
>> perf   96553 [003] 100299.663995: kmem:mm_page_alloc: page=0x1bc3f pfn=0x1bc3f order=0 migratetype=0 gfp_flags=0x40cc0
>> perf   96553 [003] 100299.664001: kmem:mm_page_alloc: page=0x1a9d9 pfn=0x1a9d9 order=0 migratetype=0 gfp_flags=0x40cc0
>> perf   96553 [003] 100299.664011: kmem:mm_page_alloc: page=0x1788b pfn=0x1788b order=0 migratetype=0 gfp_flags=0x40cc0
>> perf   96553 [003] 100299.664023: kmem:mm_page_alloc: page=0x17993 pfn=0x17993 order=0 migratetype=0 gfp_flags=0xcc0
>>
> 
> Does the same thing happen with trace-cmd record?
> 
>  # trace-cmd record -e mm_page_alloc
> [ run tests, hit Ctrl^C ]
> 
>  # trace-cmd report
> 
> ?
The trace-cmd report is the same it seems:

    perf-217873 [001] 348026.665461: mm_page_alloc:        page=0x31524d936cd pfn=0x824f5 order=0 migratetype=0 gfp_flags=0x500cc2
    perf-217873 [001] 348026.665471: mm_page_alloc:        page=0x31524e9d49a pfn=0x18c2c2 order=0 migratetype=1 gfp_flags=0x140cca
    perf-217873 [001] 348026.665474: mm_page_alloc:        page=0x31524ea8565 pfn=0x19738d order=0 migratetype=1 gfp_flags=0x140cca
    perf-217873 [001] 348026.665477: mm_page_alloc:        page=0x31524db8925 pfn=0xa774d order=0 migratetype=1 gfp_flags=0x140cca

Sending the trace.dat file as an attachment.

Thanks,
Veronika
> 
> If so, could you send the trace.dat file to me.
> 
> Thanks,
> 
> -- Steve
> 

[-- Attachment #2: trace.dat --]
[-- Type: application/octet-stream, Size: 1124903 bytes --]

Re: perf kmem --page stat and gpf_flags translation

[Veronika Molnarova]

On 11/21/24 16:03, Steven Rostedt wrote:
> On Thu, 21 Nov 2024 14:54:25 +0100 (CET)
> Michael Petlan <mpetlan@redhat.com> wrote:
> 
>> Hello Steve and others,
>>
>> We have found out that perf kmem --page stat sometimes fails like the
>> following:
>>
>> # perf kmem --page stat
>> 0x2aa28 [0x8]: failed to process type: 68 [Operation not permitted]
>> error during process events: -1
>>
>> This seem to happen on s390x KVM machines.
>>
>> When we tried to investigate for the reasons, it seems that the problem
>> is caused by incorrect/unexpected translation of gpf_flags for event
>> kmem:mm_page_alloc.
>>
>> # perf script
>> perf   96553 [003] 100299.663963: kmem:mm_page_alloc: page=0x1a8f9 pfn=0x1a8f9 order=0 migratetype=0 gfp_flags=0x500cc2
>> perf   96553 [003] 100299.663995: kmem:mm_page_alloc: page=0x1bc3f pfn=0x1bc3f order=0 migratetype=0 gfp_flags=0x40cc0
>> perf   96553 [003] 100299.664001: kmem:mm_page_alloc: page=0x1a9d9 pfn=0x1a9d9 order=0 migratetype=0 gfp_flags=0x40cc0
>> perf   96553 [003] 100299.664011: kmem:mm_page_alloc: page=0x1788b pfn=0x1788b order=0 migratetype=0 gfp_flags=0x40cc0
>> perf   96553 [003] 100299.664023: kmem:mm_page_alloc: page=0x17993 pfn=0x17993 order=0 migratetype=0 gfp_flags=0xcc0
>>
> 
> Does the same thing happen with trace-cmd record?
> 
>  # trace-cmd record -e mm_page_alloc
> [ run tests, hit Ctrl^C ]
> 
>  # trace-cmd report
> 
> ?
> 
> If so, could you send the trace.dat file to me.
> 
> Thanks,
> 
> -- Steve
> 

Hi,

is there any progress on this issue?

Thanks,
Veronika

Re: perf kmem --page stat and gpf_flags translation

[Steven Rostedt]

On Thu, 16 Jan 2025 15:34:28 +0100
Veronika Molnarova <vmolnaro@redhat.com> wrote:

> >> # perf script
> >> perf   96553 [003] 100299.663963: kmem:mm_page_alloc: page=0x1a8f9 pfn=0x1a8f9 order=0 migratetype=0 gfp_flags=0x500cc2
> >> perf   96553 [003] 100299.663995: kmem:mm_page_alloc: page=0x1bc3f pfn=0x1bc3f order=0 migratetype=0 gfp_flags=0x40cc0
> >> perf   96553 [003] 100299.664001: kmem:mm_page_alloc: page=0x1a9d9 pfn=0x1a9d9 order=0 migratetype=0 gfp_flags=0x40cc0
> >> perf   96553 [003] 100299.664011: kmem:mm_page_alloc: page=0x1788b pfn=0x1788b order=0 migratetype=0 gfp_flags=0x40cc0
> >> perf   96553 [003] 100299.664023: kmem:mm_page_alloc: page=0x17993 pfn=0x17993 order=0 migratetype=0 gfp_flags=0xcc0
> >>  
> > 
> > Does the same thing happen with trace-cmd record?
> > 
> >  # trace-cmd record -e mm_page_alloc
> > [ run tests, hit Ctrl^C ]
> > 
> >  # trace-cmd report
> > 
> > ?
> > 
> > If so, could you send the trace.dat file to me.
> > 
> > Thanks,
> > 
> > -- Steve
> >   
> 
> Hi,
> 
> is there any progress on this issue?

Sorry, the response got lost in my INBOX.

Anyway, it appears that userspace can not parse it:

$ trace-cmd dump --events /tmp/trace.dat 
        [Section 18 @ 2082: "events format", flags 0x1, 931 bytes]
        [Events format, 1 systems]
name: mm_page_alloc
ID: 510
format:
        field:unsigned short common_type;       offset:0;       size:2; signed:0;
        field:unsigned char common_flags;       offset:2;       size:1; signed:0;
        field:unsigned char common_preempt_count;       offset:3;       size:1; signed:0;
        field:int common_pid;   offset:4;       size:4; signed:1;

        field:unsigned long pfn;        offset:8;       size:8; signed:0;
        field:unsigned int order;       offset:16;      size:4; signed:0;
        field:unsigned long gfp_flags;  offset:24;      size:8; signed:0;
        field:int migratetype;  offset:32;      size:4; signed:1;

print fmt: "page=%p pfn=0x%lx order=%d migratetype=%d gfp_flags=%s", REC->pfn != -1UL ? (vmemmap + (REC->pfn)) : ((void *)0), REC->pfn != -1UL ? REC->pfn : 0, REC->order, REC->migratetype, (REC->gfp_flags) ? __print_flags(REC->gfp_flags, "|", {( unsigned long)(((((((( gfp_t)(((((1UL))) << (___GFP_DIRECT_RECLAIM_BIT))|((((1UL))) << (___GFP_KSWAPD_RECLAIM_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_IO_BIT))) | (( gfp_t)((((1UL))) << (___GFP_FS_BIT))) | (( gfp_t)((((1UL))) << (___GFP_HARDWALL_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_HIGHMEM_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_MOVABLE_BIT))) | (( gfp_t)0)) | (( gfp_t)((((1UL))) << (___GFP_COMP_BIT))) | (( gfp_t)((((1UL))) << (___GFP_NOMEMALLOC_BIT))) | (( gfp_t)((((1UL))) << (___GFP_NOWARN_BIT)))) & ~(( gfp_t)(((((1UL))) << (___GFP_DIRECT_RECLAIM_BIT))|((((1UL))) << (___GFP_KSWAPD_RECLAIM_BIT))))) | (( gfp_t)((((1UL))) << (___GFP_DIRECT_RECLAIM_BIT)))), "GFP_TRANSHUGE"}, {( unsigned long)((((((( gfp_t)(((((1UL))) << (___GFP_DIRECT_RECLAIM_BIT))|((((1UL))) << (___GFP_KSWAPD_RECLAIM_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_IO_BIT))) | (( gfp_t)((((1UL))) << (___GFP_FS_BIT))) | (( gfp_t)((((1UL))) << (___GFP_HARDWALL_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_HIGHMEM_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_MOVABLE_BIT))) | (( gfp_t)0)) | (( gfp_t)((((1UL))) << (___GFP_COMP_BIT))) | (( gfp_t)((((1UL))) << (___GFP_NOMEMALLOC_BIT))) | (( gfp_t)((((1UL))) << (___GFP_NOWARN_BIT)))) & ~(( gfp_t)(((((1UL))) << (___GFP_DIRECT_RECLAIM_BIT))|((((1UL))) << (___GFP_KSWAPD_RECLAIM_BIT))))), "GFP_TRANSHUGE_LIGHT"}, {( unsigned long)((((( gfp_t)(((((1UL))) << (___GFP_DIRECT_RECLAIM_BIT))|((((1UL))) << (___GFP_KSWAPD_RECLAIM_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_IO_BIT))) | (( gfp_t)((((1UL))) << (___GFP_FS_BIT))) | (( gfp_t)((((1UL))) << (___GFP_HARDWALL_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_HIGHMEM_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_MOVABLE_BIT))) | (( gfp_t)0)), "GFP_HIGHUSER_MOVABLE"}, {( unsigned long)(((( gfp_t)(((((1UL))) << (___GFP_DIRECT_RECLAIM_BIT))|((((1UL))) << (___GFP_KSWAPD_RECLAIM_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_IO_BIT))) | (( gfp_t)((((1UL))) << (___GFP_FS_BIT))) | (( gfp_t)((((1UL))) << (___GFP_HARDWALL_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_HIGHMEM_BIT)))), "GFP_HIGHUSER"}, {( unsigned long)((( gfp_t)(((((1UL))) << (___GFP_DIRECT_RECLAIM_BIT))|((((1UL))) << (___GFP_KSWAPD_RECLAIM_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_IO_BIT))) | (( gfp_t)((((1UL))) << (___GFP_FS_BIT))) | (( gfp_t)((((1UL))) << (___GFP_HARDWALL_BIT)))), "GFP_USER"}, {( unsigned long)(((( gfp_t)(((((1UL))) << (___GFP_DIRECT_RECLAIM_BIT))|((((1UL))) << (___GFP_KSWAPD_RECLAIM_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_IO_BIT))) | (( gfp_t)((((1UL))) << (___GFP_FS_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_ACCOUNT_BIT)))), "GFP_KERNEL_ACCOUNT"}, {( unsigned long)((( gfp_t)(((((1UL))) << (___GFP_DIRECT_RECLAIM_BIT))|((((1UL))) << (___GFP_KSWAPD_RECLAIM_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_IO_BIT))) | (( gfp_t)((((1UL))) << (___GFP_FS_BIT)))), "GFP_KERNEL"}, {( unsigned long)((( gfp_t)(((((1UL))) << (___GFP_DIRECT_RECLAIM_BIT))|((((1UL))) << (___GFP_KSWAPD_RECLAIM_BIT)))) | (( gfp_t)((((1UL))) << (___GFP_IO_BIT)))), "GFP_NOFS"}, {( unsigned long)((( gfp_t)((((1UL))) << (___GFP_HIGH_BIT)))|(( gfp_t)((((1UL))) << (___GFP_KSWAPD_RECLAIM_BIT)))), "GFP_ATOMIC"}, {( unsigned long)((( gfp_t)(((((1UL))) << (___GFP_DIRECT_RECLAIM_BIT))|((((1UL))) << (___GFP_KSWAPD_RECLAIM_BIT))))), "GFP_NOIO"}, {( unsigned long)((( gfp_t)((((1UL))) << (___GFP_KSWAPD_RECLAIM_BIT))) | (( gfp_t)((((1UL))) << (___GFP_NOWARN_BIT)))), "GFP_NOWAIT"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_DMA_BIT))), "GFP_DMA"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_HIGHMEM_BIT))), "__GFP_HIGHMEM"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_DMA32_BIT))), "GFP_DMA32"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_HIGH_BIT))), "__GFP_HIGH"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_IO_BIT))), "__GFP_IO"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_FS_BIT))), "__GFP_FS"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_NOWARN_BIT))), "__GFP_NOWARN"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_RETRY_MAYFAIL_BIT))), "__GFP_RETRY_MAYFAIL"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_NOFAIL_BIT))), "__GFP_NOFAIL"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_NORETRY_BIT))), "__GFP_NORETRY"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_COMP_BIT))), "__GFP_COMP"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_ZERO_BIT))), "__GFP_ZERO"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_NOMEMALLOC_BIT))), "__GFP_NOMEMALLOC"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_MEMALLOC_BIT))), "__GFP_MEMALLOC"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_HARDWALL_BIT))), "__GFP_HARDWALL"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_THISNODE_BIT))), "__GFP_THISNODE"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_RECLAIMABLE_BIT))), "__GFP_RECLAIMABLE"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_MOVABLE_BIT))), "__GFP_MOVABLE"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_ACCOUNT_BIT))), "__GFP_ACCOUNT"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_WRITE_BIT))), "__GFP_WRITE"}, {( unsigned long)(( gfp_t)(((((1UL))) << (___GFP_DIRECT_RECLAIM_BIT))|((((1UL))) << (___GFP_KSWAPD_RECLAIM_BIT)))), "__GFP_RECLAIM"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_DIRECT_RECLAIM_BIT))), "__GFP_DIRECT_RECLAIM"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_KSWAPD_RECLAIM_BIT))), "__GFP_KSWAPD_RECLAIM"}, {( unsigned long)(( gfp_t)((((1UL))) << (___GFP_ZEROTAGS_BIT))), "__GFP_ZEROTAGS"} ) : "none"

See all those: << (__GFP_*)

user space has no idea what numbers they represent. It should have
triggered a FAILED_TO_PARSE, but it appears that the __print_flags() hid
that error. :-/

This broke with commit: 772dd0342727c ("mm: enumerate all gfp flags") as
enums do not translate into numbers like defines do. So all gfp_flags are
now broken in user space trace tooling.

To fix this, we need to add somewhere:

TRACE_DEFINE_ENUM(___GFP_DMA_BIT);
TRACE_DEFINE_ENUM(___GFP_HIGHMEM_BIT);
TRACE_DEFINE_ENUM(___GFP_DMA32_BIT);
TRACE_DEFINE_ENUM(___GFP_MOVABLE_BIT);
TRACE_DEFINE_ENUM(___GFP_RECLAIMABLE_BIT);
TRACE_DEFINE_ENUM(___GFP_HIGH_BIT);
TRACE_DEFINE_ENUM(___GFP_IO_BIT);
TRACE_DEFINE_ENUM(___GFP_FS_BIT);
TRACE_DEFINE_ENUM(___GFP_ZERO_BIT);
TRACE_DEFINE_ENUM(___GFP_UNUSED_BIT);
TRACE_DEFINE_ENUM(___GFP_DIRECT_RECLAIM_BIT);
TRACE_DEFINE_ENUM(___GFP_KSWAPD_RECLAIM_BIT);
TRACE_DEFINE_ENUM(___GFP_WRITE_BIT);
TRACE_DEFINE_ENUM(___GFP_NOWARN_BIT);
TRACE_DEFINE_ENUM(___GFP_RETRY_MAYFAIL_BIT);
TRACE_DEFINE_ENUM(___GFP_NOFAIL_BIT);
TRACE_DEFINE_ENUM(___GFP_NORETRY_BIT);
TRACE_DEFINE_ENUM(___GFP_MEMALLOC_BIT);
TRACE_DEFINE_ENUM(___GFP_COMP_BIT);
TRACE_DEFINE_ENUM(___GFP_NOMEMALLOC_BIT);
TRACE_DEFINE_ENUM(___GFP_HARDWALL_BIT);
TRACE_DEFINE_ENUM(___GFP_THISNODE_BIT);
TRACE_DEFINE_ENUM(___GFP_ACCOUNT_BIT);
TRACE_DEFINE_ENUM(___GFP_ZEROTAGS_BIT);
#ifdef CONFIG_KASAN_HW_TAGS
TRACE_DEFINE_ENUM(___GFP_SKIP_ZERO_BIT);
TRACE_DEFINE_ENUM(___GFP_SKIP_KASAN_BIT);
#endif
#ifdef CONFIG_LOCKDEP
TRACE_DEFINE_ENUM(___GFP_NOLOCKDEP_BIT);
#endif
TRACE_DEFINE_ENUM(___GFP_LAST_BIT);

That will convert the enums into numbers in the trace event format files.


-- Steve