From: Beau Belgrave <beaub@linux.microsoft.com>
To: peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
namhyung@kernel.org, rostedt@goodmis.org, mhiramat@kernel.org,
mathieu.desnoyers@efficios.com
Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org, mark.rutland@arm.com,
alexander.shishkin@linux.intel.com, jolsa@kernel.org,
irogers@google.com, adrian.hunter@intel.com, primiano@google.com,
aahringo@redhat.com, dcook@linux.microsoft.com
Subject: [RFC PATCH 1/4] perf/core: Introduce perf_prepare_dump_data()
Date: Fri, 12 Apr 2024 00:17:29 +0000 [thread overview]
Message-ID: <20240412001732.475-2-beaub@linux.microsoft.com> (raw)
In-Reply-To: <20240412001732.475-1-beaub@linux.microsoft.com>
Factor out perf_prepare_dump_data() so that the same logic is used for
dumping stack data as other types, such as TLS.
Slightly refactor perf_sample_ustack_size() to perf_sample_dump_size().
Move reg checks up into perf_ustack_task_size() since the task size
must now be calculated before preparing dump data.
Signed-off-by: Beau Belgrave <beaub@linux.microsoft.com>
---
kernel/events/core.c | 79 ++++++++++++++++++++++++++------------------
1 file changed, 47 insertions(+), 32 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 724e6d7e128f..07de5cc2aa25 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6912,7 +6912,13 @@ static void perf_sample_regs_intr(struct perf_regs *regs_intr,
*/
static u64 perf_ustack_task_size(struct pt_regs *regs)
{
- unsigned long addr = perf_user_stack_pointer(regs);
+ unsigned long addr;
+
+ /* No regs, no stack pointer, no dump. */
+ if (!regs)
+ return 0;
+
+ addr = perf_user_stack_pointer(regs);
if (!addr || addr >= TASK_SIZE)
return 0;
@@ -6921,42 +6927,35 @@ static u64 perf_ustack_task_size(struct pt_regs *regs)
}
static u16
-perf_sample_ustack_size(u16 stack_size, u16 header_size,
- struct pt_regs *regs)
+perf_sample_dump_size(u16 dump_size, u16 header_size, u64 task_size)
{
- u64 task_size;
-
- /* No regs, no stack pointer, no dump. */
- if (!regs)
- return 0;
-
/*
- * Check if we fit in with the requested stack size into the:
+ * Check if we fit in with the requested dump size into the:
* - TASK_SIZE
* If we don't, we limit the size to the TASK_SIZE.
*
* - remaining sample size
- * If we don't, we customize the stack size to
+ * If we don't, we customize the dump size to
* fit in to the remaining sample size.
*/
- task_size = min((u64) USHRT_MAX, perf_ustack_task_size(regs));
- stack_size = min(stack_size, (u16) task_size);
+ task_size = min((u64) USHRT_MAX, task_size);
+ dump_size = min(dump_size, (u16) task_size);
/* Current header size plus static size and dynamic size. */
header_size += 2 * sizeof(u64);
- /* Do we fit in with the current stack dump size? */
- if ((u16) (header_size + stack_size) < header_size) {
+ /* Do we fit in with the current dump size? */
+ if ((u16) (header_size + dump_size) < header_size) {
/*
* If we overflow the maximum size for the sample,
- * we customize the stack dump size to fit in.
+ * we customize the dump size to fit in.
*/
- stack_size = USHRT_MAX - header_size - sizeof(u64);
- stack_size = round_up(stack_size, sizeof(u64));
+ dump_size = USHRT_MAX - header_size - sizeof(u64);
+ dump_size = round_up(dump_size, sizeof(u64));
}
- return stack_size;
+ return dump_size;
}
static void
@@ -7648,6 +7647,32 @@ static __always_inline u64 __cond_set(u64 flags, u64 s, u64 d)
return d * !!(flags & s);
}
+static inline u16
+perf_prepare_dump_data(struct perf_sample_data *data,
+ struct perf_event *event,
+ struct pt_regs *regs,
+ u16 dump_size,
+ u64 task_size)
+{
+ u16 header_size = perf_sample_data_size(data, event);
+ u16 size = sizeof(u64);
+
+ dump_size = perf_sample_dump_size(dump_size, header_size,
+ task_size);
+
+ /*
+ * If there is something to dump, add space for the dump
+ * itself and for the field that tells the dynamic size,
+ * which is how many have been actually dumped.
+ */
+ if (dump_size)
+ size += sizeof(u64) + dump_size;
+
+ data->dyn_size += size;
+
+ return dump_size;
+}
+
void perf_prepare_sample(struct perf_sample_data *data,
struct perf_event *event,
struct pt_regs *regs)
@@ -7725,22 +7750,12 @@ void perf_prepare_sample(struct perf_sample_data *data,
* up the rest of the sample size.
*/
u16 stack_size = event->attr.sample_stack_user;
- u16 header_size = perf_sample_data_size(data, event);
- u16 size = sizeof(u64);
-
- stack_size = perf_sample_ustack_size(stack_size, header_size,
- data->regs_user.regs);
+ u64 task_size = perf_ustack_task_size(regs);
- /*
- * If there is something to dump, add space for the dump
- * itself and for the field that tells the dynamic size,
- * which is how many have been actually dumped.
- */
- if (stack_size)
- size += sizeof(u64) + stack_size;
+ stack_size = perf_prepare_dump_data(data, event, regs,
+ stack_size, task_size);
data->stack_user_size = stack_size;
- data->dyn_size += size;
data->sample_flags |= PERF_SAMPLE_STACK_USER;
}
--
2.34.1
next prev parent reply other threads:[~2024-04-12 0:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-12 0:17 [RFC PATCH 0/4] perf: Correlating user process data to samples Beau Belgrave
2024-04-12 0:17 ` Beau Belgrave [this message]
2024-04-12 0:17 ` [RFC PATCH 2/4] perf: Introduce PERF_SAMPLE_TLS_USER sample type Beau Belgrave
2024-04-12 0:17 ` [RFC PATCH 3/4] perf/core: Factor perf_output_sample_udump() Beau Belgrave
2024-04-12 0:17 ` [RFC PATCH 4/4] perf/x86/core: Add tls dump support Beau Belgrave
2024-04-12 4:52 ` [RFC PATCH 0/4] perf: Correlating user process data to samples Ian Rogers
2024-04-12 16:28 ` Beau Belgrave
2024-04-12 18:32 ` Mathieu Desnoyers
2024-04-12 7:12 ` Peter Zijlstra
2024-04-12 16:37 ` Beau Belgrave
2024-04-13 10:53 ` Peter Zijlstra
2024-04-13 12:48 ` Steven Rostedt
2024-04-18 22:53 ` Josh Poimboeuf
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=20240412001732.475-2-beaub@linux.microsoft.com \
--to=beaub@linux.microsoft.com \
--cc=aahringo@redhat.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=dcook@linux.microsoft.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=primiano@google.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 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.