From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Beau Belgrave <beaub@linux.microsoft.com>
Cc: rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
linux-trace-devel <linux-trace-devel@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH 6/7] tracing/user_events: Use bits vs bytes for enabled status page data
Date: Tue, 19 Apr 2022 10:35:45 -0400 (EDT) [thread overview]
Message-ID: <337584634.26921.1650378945485.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20220401234309.21252-7-beaub@linux.microsoft.com>
----- On Apr 1, 2022, at 7:43 PM, Beau Belgrave beaub@linux.microsoft.com wrote:
> User processes may require many events and when they do the cache
> performance of a byte index status check is less ideal than a bit index.
> The previous event limit per-page was 4096, the new limit is 32,768.
>
> This change adds a mask property to the user_reg struct. Programs check
> that the byte at status_index has a bit set by ANDing the status_mask.
>
> Link:
> https://lore.kernel.org/all/2059213643.196683.1648499088753.JavaMail.zimbra@efficios.com/
>
> Suggested-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Signed-off-by: Beau Belgrave <beaub@linux.microsoft.com>
Hi Beau,
Considering this will be used in a fast-path, why choose bytewise
loads for the byte at status_index and the status_mask ?
I'm concerned about the performance penalty associated with partial
register stalls when working with bytewise ALU operations rather than
operations using the entire registers.
Ideally I would be tempted to use "unsigned long" type (32-bit on 32-bit
binaries and 64-bit on 64-bit binaries) for both the array access
and the status mask, but this brings extra complexity for 32-bit compat
handling.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2022-04-19 14:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-01 23:43 [PATCH 0/7] tracing/user_events: Update user_events ABI from Beau Belgrave
2022-04-01 23:43 ` [PATCH 1/7] tracing/user_events: Fix repeated word in comments Beau Belgrave
2022-04-01 23:43 ` [PATCH 2/7] tracing/user_events: Use NULL for strstr checks Beau Belgrave
2022-04-01 23:43 ` [PATCH 3/7] tracing/user_events: Use WRITE instead of READ for io vector import Beau Belgrave
2022-04-01 23:43 ` [PATCH 4/7] tracing/user_events: Ensure user provided strings are safely formatted Beau Belgrave
2022-04-01 23:43 ` [PATCH 5/7] tracing/user_events: Use refcount instead of atomic for ref tracking Beau Belgrave
2022-04-01 23:43 ` [PATCH 6/7] tracing/user_events: Use bits vs bytes for enabled status page data Beau Belgrave
2022-04-19 14:35 ` Mathieu Desnoyers [this message]
2022-04-19 18:57 ` Beau Belgrave
2022-04-19 21:26 ` Mathieu Desnoyers
2022-04-19 23:48 ` Beau Belgrave
2022-04-20 17:53 ` Mathieu Desnoyers
2022-04-20 20:12 ` Beau Belgrave
2022-04-20 20:21 ` Mathieu Desnoyers
2022-04-01 23:43 ` [PATCH 7/7] tracing/user_events: Update ABI documentation to align to bits vs bytes Beau Belgrave
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=337584634.26921.1650378945485.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=beaub@linux.microsoft.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-devel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--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 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.