All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: rostedt <rostedt@goodmis.org>
Cc: Namhyung Kim <namhyung@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>, Will Deacon <will@kernel.org>,
	Waiman Long <longman@redhat.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Byungchul Park <byungchul.park@lge.com>,
	paulmck <paulmck@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Radoslaw Burny <rburny@google.com>,
	linux-arch <linux-arch@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH 1/2] locking: Add lock contention tracepoints
Date: Thu, 17 Mar 2022 12:37:41 -0400 (EDT)	[thread overview]
Message-ID: <1649265824.157580.1647535061743.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20220317120753.4cd73f9e@gandalf.local.home>

----- On Mar 17, 2022, at 12:07 PM, rostedt rostedt@goodmis.org wrote:

> On Thu, 17 Mar 2022 09:32:55 -0400 (EDT)
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> 
>> Unless there is a particular reason for using preprocessor defines here, the
>> following form is typically better because it does not pollute the preprocessor
>> defines, e.g.:
>> 
>> enum lock_contention_flags {
>>         LCB_F_SPIN =   1U << 0;
>>         LCB_F_READ =   1U << 1;
>>         LCB_F_WRITE =  1U << 2;
>>         LCB_F_RT =     1U << 3;
>>         LCB_F_PERCPU = 1U << 4;
>> };
> 
> If you do this, then to use the __print_flags(), You'll also need to add:
> 
> TRACE_DEFINE_ENUM(LCB_F_SPIN);
> TRACE_DEFINE_ENUM(LCB_F_READ);
> TRACE_DEFINE_ENUM(LCB_F_WRITE);
> TRACE_DEFINE_ENUM(LCB_F_RT);
> TRACE_DEFINE_ENUM(LCB_F_PERCPU);
> 
> Which does slow down boot up slightly.

So it looks like there is (currently) a good reason for going with the #define.

As a side-discussion, I keep finding it odd that this adds overhead on boot. I suspect
this is also implemented as a linked list which needs to be iterated over at boot-time.

With a few changes to these macros, these linked lists could be turned into arrays,
and thus remove the boot-time overhead.

Thanks,

Mathieu

> 
> -- Steve

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

  reply	other threads:[~2022-03-17 16:37 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-16 22:45 [PATCH 0/2] locking: Add new lock contention tracepoints (v3) Namhyung Kim
2022-03-16 22:45 ` [PATCH 1/2] locking: Add lock contention tracepoints Namhyung Kim
2022-03-17  2:31   ` Steven Rostedt
2022-03-17 13:32   ` Mathieu Desnoyers
2022-03-17 16:07     ` Steven Rostedt
2022-03-17 16:37       ` Mathieu Desnoyers [this message]
2022-03-18 20:58         ` Namhyung Kim
2022-03-16 22:45 ` [PATCH 2/2] locking: Apply contention tracepoints in the slow path Namhyung Kim
2022-03-17 13:45   ` Mathieu Desnoyers
2022-03-17 16:10     ` Steven Rostedt
2022-03-17 16:43       ` Mathieu Desnoyers
2022-03-18 21:34     ` Namhyung Kim
2022-03-17 18:19   ` Hyeonggon Yoo
2022-03-18 21:43     ` Namhyung Kim
2022-03-18 12:55   ` Boqun Feng
2022-03-18 13:24     ` Hyeonggon Yoo
2022-03-18 13:28       ` Hyeonggon Yoo
2022-03-18 16:43     ` Peter Zijlstra
2022-03-18 21:55       ` Namhyung Kim
2022-03-18 22:07         ` Steven Rostedt
2022-03-19  0:11           ` Namhyung Kim
2022-03-22  5:31             ` Namhyung Kim
2022-03-22 12:59               ` Steven Rostedt
2022-03-22 16:39                 ` Namhyung Kim
2022-03-17 17:32 ` [PATCH 0/2] locking: Add new lock contention tracepoints (v3) Hyeonggon Yoo
2022-03-18 21:12   ` Namhyung Kim
  -- strict thread matches above, loose matches on Subject: below --
2022-03-22 18:57 [PATCH 0/2] locking: Add new lock contention tracepoints (v4) Namhyung Kim
2022-03-22 18:57 ` [PATCH 1/2] locking: Add lock contention tracepoints Namhyung Kim

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=1649265824.157580.1647535061743.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=arnd@arndb.de \
    --cc=boqun.feng@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=byungchul.park@lge.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rburny@google.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.