[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YK+JfHHNbvV7odqX@localhost.localdomain>
Date: Thu, 27 May 2021 13:58:52 +0200
From: Juri Lelli <juri.lelli@...hat.com>
To: Daniel Bristot de Oliveira <bristot@...hat.com>
Cc: linux-kernel@...r.kernel.org, Phil Auld <pauld@...hat.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Kate Carcia <kcarcia@...hat.com>,
Jonathan Corbet <corbet@....net>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Alexandre Chartre <alexandre.chartre@...cle.com>,
Clark Willaims <williams@...hat.com>,
John Kacur <jkacur@...hat.com>, linux-doc@...r.kernel.org
Subject: Re: [PATCH V3 4/9] tracing/hwlat: Implement the per-cpu mode
Hi,
On 14/05/21 22:51, Daniel Bristot de Oliveira wrote:
[...]
> +/**
> + * start_per_cpu_kthread - Kick off the hardware latency sampling/detector kthreads
> + *
> + * This starts the kernel threads that will sit on potentially all cpus and
> + * sample the CPU timestamp counter (TSC or similar) and look for potential
> + * hardware latencies.
> + */
> +static int start_per_cpu_kthreads(struct trace_array *tr)
> +{
> + struct cpumask *current_mask = &save_cpumask;
> + struct cpumask *this_cpumask;
> + struct task_struct *kthread;
> + char comm[24];
> + int cpu;
> +
> + if (!alloc_cpumask_var(&this_cpumask, GFP_KERNEL))
> + return -ENOMEM;
Is this_cpumask actually used anywhere?
Thanks,
Juri
Powered by blists - more mailing lists