From: Steven Rostedt <rostedt@goodmis.org>
To: LKML <linux-kernel@vger.kernel.org>,
Linux Trace Kernel <linux-trace-kernel@vger.kernel.org>,
linux-mm@kvack.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Andrew Morton <akpm@linux-foundation.org>,
Michael Petlan <mpetlan@redhat.com>,
Veronika Molnarova <vmolnaro@redhat.com>,
Suren Baghdasaryan <surenb@google.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RESEND][PATCH] tracing: gfp: Remove duplication of recording GFP flags
Date: Tue, 25 Feb 2025 14:56:02 -0500 [thread overview]
Message-ID: <20250225145602.59e61cdb@gandalf.local.home> (raw)
In-Reply-To: <20250225135611.1942b65c@gandalf.local.home>
On Tue, 25 Feb 2025 13:56:11 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> Last version: https://lore.kernel.org/20250116214439.046082618@goodmis.org
>
> This was originally sent with a patch that fixed the output of gfp flags
> in trace events to show human readable flags and not hex numbers.
>
> This patch on the other hand is a clean up as the there's now two macros
> that define the bits to print. This makes the one macro use the other
> macro that is a subset of the first.
>
> Can someone in the memory management subsystem either give me an acked-by
> and I can take this through my tree, or you can just take this through
> the memory management tree. Either way works for me.
Interesting, I even ran a before and after of this patch by doing the following:
# trace-cmd start -e dma -e vmscan -e percpu -e kmem
[ wait a few minutes ]
# trace-cmd show |grep gfp > ~/gfp-before
[ apply patch, compile, install, reboot ]
# trace-cmd start -e dma -e vmscan -e percpu -e kmem
[ wait a few minutes ]
# trace-cmd show |grep gfp > ~/gfp-after
# perl -e 'while (<>) { if (/gfp_flags=(\S+)/) { print "$1\n"; } }' < gfp-before | sort -u > /tmp/before.sort
# perl -e 'while (<>) { if (/gfp_flags=(\S+)/) { print "$1\n"; } }' < gfp-after | sort -u > /tmp/after.sort
# diff -u /tmp/before.sort /tmp/after.sort
--- /tmp/before.sort 2025-02-25 14:41:49.799742048 -0500
+++ /tmp/after.sort 2025-02-25 14:41:41.247636893 -0500
@@ -4,38 +4,39 @@
GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP
GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC
GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_NOMEMALLOC
-GFP_ATOMIC|__GFP_ZERO|0x2000000
+GFP_ATOMIC|__GFP_ZERO|__GFP_COMP|__GFP_NO_OBJ_EXT
GFP_HIGHUSER|__GFP_ACCOUNT
GFP_HIGHUSER_MOVABLE|__GFP_COMP
-GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_WRITE
-GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO
+GFP_HIGHUSER_MOVABLE|__GFP_WRITE|__GFP_COMP
+GFP_HIGHUSER_MOVABLE|__GFP_ZERO|__GFP_COMP
__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC
-__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_RECLAIMABLE
-__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_RECLAIMABLE
GFP_KERNEL
GFP_KERNEL_ACCOUNT
-GFP_KERNEL_ACCOUNT|__GFP_COMP|__GFP_ZERO
+GFP_KERNEL_ACCOUNT|__GFP_NOWARN|__GFP_NOMEMALLOC
GFP_KERNEL_ACCOUNT|__GFP_ZERO
-GFP_KERNEL|__GFP_COMP|__GFP_ZERO|0x2000000
+GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_COMP
GFP_KERNEL|__GFP_NOWARN|__GFP_NOMEMALLOC
-GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP
GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_NOMEMALLOC
GFP_KERNEL|__GFP_ZERO
+GFP_KERNEL|__GFP_ZERO|__GFP_COMP|__GFP_NO_OBJ_EXT
+GFP_KERNEL|__GFP_ZERO|__GFP_NO_OBJ_EXT
GFP_NOFS
-GFP_NOFS|__GFP_COMP|__GFP_ZERO|0x2000000
-GFP_NOFS|__GFP_NOFAIL|__GFP_COMP|__GFP_HARDWALL|__GFP_MOVABLE
-GFP_NOFS|__GFP_NOFAIL|__GFP_ZERO
-GFP_NOFS|__GFP_NOFAIL|__GFP_ZERO|__GFP_ACCOUNT
-GFP_NOFS|__GFP_NOFAIL|__GFP_ZERO|__GFP_HARDWALL|__GFP_MOVABLE|__GFP_ACCOUNT
+GFP_NOFS|__GFP_MOVABLE|__GFP_NOFAIL|__GFP_COMP|__GFP_HARDWALL
+GFP_NOFS|__GFP_MOVABLE|__GFP_ZERO|__GFP_NOFAIL|__GFP_HARDWALL|__GFP_ACCOUNT
+GFP_NOFS|__GFP_NOFAIL
GFP_NOFS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP
-GFP_NOFS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_RECLAIMABLE
GFP_NOFS|__GFP_NOWARN|__GFP_NORETRY|__GFP_NOMEMALLOC
+GFP_NOFS|__GFP_RECLAIMABLE|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP
GFP_NOFS|__GFP_ZERO
-GFP_NOFS|__GFP_ZERO|0x2000000
+GFP_NOFS|__GFP_ZERO|__GFP_NOFAIL
+GFP_NOFS|__GFP_ZERO|__GFP_NOFAIL|__GFP_ACCOUNT
+GFP_NOFS|__GFP_ZERO|__GFP_NO_OBJ_EXT
GFP_NOWAIT
GFP_NOWAIT|__GFP_ACCOUNT
-GFP_NOWAIT|__GFP_IO|__GFP_FS|__GFP_NORETRY|__GFP_COMP
+GFP_NOWAIT|__GFP_COMP
GFP_NOWAIT|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC
-GFP_NOWAIT|__GFP_NORETRY|__GFP_COMP|__GFP_RECLAIMABLE
GFP_NOWAIT|__GFP_NORETRY|__GFP_NOMEMALLOC
-GFP_NOWAIT|__GFP_ZERO|0x2000000
+GFP_NOWAIT|__GFP_RECLAIMABLE|__GFP_NORETRY|__GFP_COMP
+GFP_NOWAIT|__GFP_ZERO|__GFP_ACCOUNT
+GFP_NOWAIT|__GFP_ZERO|__GFP_NO_OBJ_EXT
+__GFP_RECLAIMABLE|__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC
Notice that the old way has:
-GFP_NOFS|__GFP_COMP|__GFP_ZERO|0x2000000
And I looked at what that 0x2000000 is, and for my current config, it is:
__GFP_NO_OBJ_EXT
Which was completely missing from the old way, and this patch actually
picks it up!
That's because the TRACE_GFP_FLAGS has it, but the __def_gfpflag_names
macro was missing it. Again, it's better to remove having to maintain two
lists instead of just one.
-- Steve
next prev parent reply other threads:[~2025-02-25 19:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-25 18:56 Steven Rostedt
2025-02-25 19:56 ` Steven Rostedt [this message]
2025-02-28 22:50 ` Steven Rostedt
2025-03-13 15:26 ` Petr Mladek
2025-03-13 16:53 ` Steven Rostedt
2025-03-14 12:25 ` Steven Rostedt
2025-03-14 14:13 ` [PATCH] tracing: gfp: vsprintf: Do not print "none" when using %pGg printf format Petr Mladek
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=20250225145602.59e61cdb@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mpetlan@redhat.com \
--cc=surenb@google.com \
--cc=torvalds@linux-foundation.org \
--cc=vmolnaro@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox