From: Vlastimil Babka <vbabka@suse.cz>
To: Gang Li <ligang.bdlg@bytedance.com>, rostedt@goodmis.org
Cc: mingo@redhat.com, akpm@linux-foundation.org,
axelrasmussen@google.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v2 2/2] mm: mmap_lock: use DECLARE_EVENT_CLASS and DEFINE_EVENT_FN
Date: Mon, 11 Oct 2021 10:02:42 +0200 [thread overview]
Message-ID: <9eede0f3-cc9e-753b-16f1-0f5c3ad57794@suse.cz> (raw)
In-Reply-To: <20211009071243.70286-1-ligang.bdlg@bytedance.com>
On 10/9/21 09:12, Gang Li wrote:
> By using DECLARE_EVENT_CLASS and TRACE_EVENT_FN, we can save a lot
> of space from duplicate code.
>
> Signed-off-by: Gang Li <ligang.bdlg@bytedance.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
> @@ -36,11 +36,19 @@ TRACE_EVENT_FN(mmap_lock_start_locking,
> __entry->mm,
> __get_str(memcg_path),
> __entry->write ? "true" : "false"
> - ),
> -
> - trace_mmap_lock_reg, trace_mmap_lock_unreg
> + )
> );
>
> +#define DEFINE_MMAP_LOCK_EVENT(name) \
> + DEFINE_EVENT_FN(mmap_lock, name, \
> + TP_PROTO(struct mm_struct *mm, const char *memcg_path, \
> + bool write), \
> + TP_ARGS(mm, memcg_path, write), \
> + trace_mmap_lock_reg, trace_mmap_lock_unreg)
A question (for Steven). I've several times wondered why DEFINE_EVENT has to
pass TP_PROTO/TP_ARGS even if they are often the same. Is it not possible to
have a variant that doesn't need that, and thus also doesn't need such extra
wrapping as above?
> +
> +DEFINE_MMAP_LOCK_EVENT(mmap_lock_start_locking);
> +DEFINE_MMAP_LOCK_EVENT(mmap_lock_released);
> +
> TRACE_EVENT_FN(mmap_lock_acquire_returned,
>
> TP_PROTO(struct mm_struct *mm, const char *memcg_path, bool write,
> @@ -73,34 +81,6 @@ TRACE_EVENT_FN(mmap_lock_acquire_returned,
> trace_mmap_lock_reg, trace_mmap_lock_unreg
> );
>
> -TRACE_EVENT_FN(mmap_lock_released,
> -
> - TP_PROTO(struct mm_struct *mm, const char *memcg_path, bool write),
> -
> - TP_ARGS(mm, memcg_path, write),
> -
> - TP_STRUCT__entry(
> - __field(struct mm_struct *, mm)
> - __string(memcg_path, memcg_path)
> - __field(bool, write)
> - ),
> -
> - TP_fast_assign(
> - __entry->mm = mm;
> - __assign_str(memcg_path, memcg_path);
> - __entry->write = write;
> - ),
> -
> - TP_printk(
> - "mm=%p memcg_path=%s write=%s",
> - __entry->mm,
> - __get_str(memcg_path),
> - __entry->write ? "true" : "false"
> - ),
> -
> - trace_mmap_lock_reg, trace_mmap_lock_unreg
> -);
> -
> #endif /* _TRACE_MMAP_LOCK_H */
>
> /* This part must be outside protection */
>
prev parent reply other threads:[~2021-10-11 8:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-09 7:12 Gang Li
2021-10-10 21:49 ` Steven Rostedt
2021-10-11 8:02 ` Vlastimil Babka [this message]
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=9eede0f3-cc9e-753b-16f1-0f5c3ad57794@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=ligang.bdlg@bytedance.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
/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