To avoid mixup of packets from differnt ftrace packets simultaneously,
use different channel for packets from different CPU.
Signed-off-by: Tingwei Zhang <[email protected]>
Reviewed-by: Steven Rostedt (VMware) <[email protected]>
---
drivers/hwtracing/stm/ftrace.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/stm/ftrace.c b/drivers/hwtracing/stm/ftrace.c
index c694a6e692d1..ebf29489919c 100644
--- a/drivers/hwtracing/stm/ftrace.c
+++ b/drivers/hwtracing/stm/ftrace.c
@@ -37,8 +37,10 @@ static void notrace
stm_ftrace_write(struct trace_export *export, const void *buf, unsigned int len)
{
struct stm_ftrace *stm = container_of(export, struct stm_ftrace, ftrace);
+ /* This is called from trace system with preemption disabled */
+ unsigned int cpu = smp_processor_id();
- stm_source_write(&stm->data, STM_FTRACE_CHAN, buf, len);
+ stm_source_write(&stm->data, STM_FTRACE_CHAN + cpu, buf, len);
}
static int stm_ftrace_link(struct stm_source_data *data)
@@ -63,6 +65,7 @@ static int __init stm_ftrace_init(void)
{
int ret;
+ stm_ftrace.data.nr_chans = num_possible_cpus();
ret = stm_source_register_device(NULL, &stm_ftrace.data);
if (ret)
pr_err("Failed to register stm_source - ftrace.\n");
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Tingwei Zhang <[email protected]> writes:
> @@ -63,6 +65,7 @@ static int __init stm_ftrace_init(void)
> {
> int ret;
>
> + stm_ftrace.data.nr_chans = num_possible_cpus();
Not a problem with this patch necesarily, but this made me realize that
.nr_chans may be larger than:
(1) what the policy permits,
(2) what the stm device can handle.
While (1) the user can fix in the policy, they won't be able to fix (2),
in which case they won't be able to use stm_ftrace at all. I'm thinking
if a link-time callback would be good enough.
Another thing is that .nr_chans needs to be a power of 2 at the moment.
Regards,
--
Alex
On Fri, Sep 18, 2020 at 08:45:52PM +0800, Alexander Shishkin wrote:
> Tingwei Zhang <[email protected]> writes:
>
> > @@ -63,6 +65,7 @@ static int __init stm_ftrace_init(void)
> > {
> > int ret;
> >
> > + stm_ftrace.data.nr_chans = num_possible_cpus();
>
> Not a problem with this patch necesarily, but this made me realize that
> .nr_chans may be larger than:
>
> (1) what the policy permits,
> (2) what the stm device can handle.
>
> While (1) the user can fix in the policy, they won't be able to fix (2),
> in which case they won't be able to use stm_ftrace at all. I'm thinking
> if a link-time callback would be good enough.
>
Hi Alex,
I'm not sure if I understand this correct. If the nr_chans requested by
stm_ftrace is larger than policy permits or stm device can handle,
stm_assign_first_policy() returns with error so stm_source_link_add()
will fail. User would notice that when link happens. There's not much
we can do if resource is not enough.
> Another thing is that .nr_chans needs to be a power of 2 at the moment.
>
I'll change to below.
stm_ftrace.data.nr_chans = roundup_pow_of_two(num_possible_cpus());
> Regards,
> --
> Alex
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel