[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170213122517.6e211955@redhat.com>
Date: Mon, 13 Feb 2017 12:25:17 -0500
From: Luiz Capitulino <lcapitulino@...hat.com>
To: linux-kernel@...r.kernel.org
Cc: rostedt@...dmis.org
Subject: [PATCH] tracing: hwlat: update old comment
The ftrace hwlat does support a cpumask.
Signed-off-by: Luiz Capitulino <lcapitulino@...hat.com>
---
kernel/trace/trace_hwlat.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/kernel/trace/trace_hwlat.c b/kernel/trace/trace_hwlat.c
index af344a1b..1199fe1 100644
--- a/kernel/trace/trace_hwlat.c
+++ b/kernel/trace/trace_hwlat.c
@@ -322,10 +322,7 @@ static void move_to_next_cpu(bool initmask)
* need to ensure nothing else might be running (and thus preempting).
* Obviously this should never be used in production environments.
*
- * Currently this runs on which ever CPU it was scheduled on, but most
- * real-world hardware latency situations occur across several CPUs,
- * but we might later generalize this if we find there are any actualy
- * systems with alternate SMI delivery or other hardware latencies.
+ * Executes one loop interaction on each CPU in tracing_cpumask sysfs file.
*/
static int kthread_fn(void *data)
{
--
2.5.5
Powered by blists - more mailing lists