Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp398707ybn; Tue, 1 Oct 2019 23:21:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqyIAqI7gSW9IIBi0M8Eb+rilisqKDbGla8/+UpyJJ4ErtypzWlAxaRFcn+dMQEim9CSeTra X-Received: by 2002:a17:906:9498:: with SMTP id t24mr1586988ejx.88.1569997267422; Tue, 01 Oct 2019 23:21:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569997267; cv=none; d=google.com; s=arc-20160816; b=tfdOPXMk6b7ag30KLB5fVHZiovUdFKUtdw3u5jXDOCKOA/Zd4t/MLrjGubUm9HNcre I6XpPyMiY0bZUtMV6U1cC3JkKJJrna1PCvLrxIr3Aaneb0GlOBIBaU2lKDEtWyYLqFIz JTj/kjRV4bEqFcu01zzC9QijqX/A3/FUbdId+FE/UcLNNq8YCTSrO1qcM2d18RTOhEOz IYg9LTmnHsTyZMdRva6BgS4dM1odYggpCyNQeVgo0fW2/uoIlG1dQlzSeU/DLLmgIUAH heQ0m+bObmpVMLUmHCBC0EkOxvc2EsYOpKyKYWDGzjhcM9iDGV02W/muyzkTT4gTkE1u EmIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=EA3hp0Xv+I7s31syYAJyUxFj/BGRxBB7nEHlDT4FJyw=; b=hqbceaGsF9rliUOTuKlTDZQtTeK21AEmZLAgTlPESh1Yb8kRQw/QbdUs2N4jx9eX7L 08kZ1Buin3b/QZj1lIoaAEABl7lN8F1fkJte4B2HLijsw5IVss1gD+FUCHy5buoii3gd XaDnezIIy08i59gNuZrehC4Mw31wiOQ9uOF/V4rhUDgzrtPg0ZGd3mj2EhMLYO7AqX6g H01P1ZQORfMsDOpbzVwkcV4gkiHKo0uk43LKWyHA6pkoILjodgmAZxbovKjkqAH8YKUN dpjwunfYl2V8TIskUR9hCHQxuYAqSzxta0eu+7WMc/rsRAIE9ROQN1B+JDZdJaxx/lxz X/nw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=iqp7Ug5L; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j46si10715405eda.9.2019.10.01.23.20.43; Tue, 01 Oct 2019 23:21:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=iqp7Ug5L; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727131AbfJBAcG (ORCPT + 99 others); Tue, 1 Oct 2019 20:32:06 -0400 Received: from mail-pf1-f195.google.com ([209.85.210.195]:44401 "EHLO mail-pf1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726463AbfJBAcG (ORCPT ); Tue, 1 Oct 2019 20:32:06 -0400 Received: by mail-pf1-f195.google.com with SMTP id q21so9313358pfn.11 for ; Tue, 01 Oct 2019 17:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=EA3hp0Xv+I7s31syYAJyUxFj/BGRxBB7nEHlDT4FJyw=; b=iqp7Ug5LU/j2TV30HttlIxqrhUSmLd4IwvawQ3MJe6dS+htu94Vz9g5HTvkD/DwD5d 0dAHS3oSwcHWjOfWe0Fw+YYswWi7C6hmAXTB4Eat+68lAbvle7zhRSldOTEn81zfyVhL J+lijyEnR0qWYlpB3Q4FDj7YlirJIouOI37DU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=EA3hp0Xv+I7s31syYAJyUxFj/BGRxBB7nEHlDT4FJyw=; b=Hts36gWUSFK56a6K1FywxTEITLAj8z2G2JL1gA9F1E27Yvl7fLGpiHEwErx58cPE0i xiph6j2PyVb8sfnH8lU2Xh1YBjBgE1k0LT5ql4WMWpiFMmMLhn0rEPcMhTGhuaH5qFAo 4za73B4mKAIQq3JdUlCVZiktBByWNQUQWqEuDJlBz2JewBBucAFN68ndNH7EglThsbwo E+yu0HfmVyhbPuSlrWphVx2NJZFZiR0M8hFSJU6cUPX1vC46vJT0oX9oJADvmCln3/YE pUaEgQMEH+7VOIBDWpir6o7yAkSM91nhIur1WR3/EiJ9e6JYAqIct1eCuLcQULyCDDHC bXWg== X-Gm-Message-State: APjAAAXkni8ZVWKDU7zlxoaZbd2794b0DXat7XC1aIaJRaZ3vg0jF1N+ gBcT7/QwoA2C3qACnXsKSG//6A== X-Received: by 2002:a17:90a:9d87:: with SMTP id k7mr1072747pjp.103.1569976324717; Tue, 01 Oct 2019 17:32:04 -0700 (PDT) Received: from localhost ([2620:15c:6:12:9c46:e0da:efbf:69cc]) by smtp.gmail.com with ESMTPSA id b16sm27904391pfb.54.2019.10.01.17.32.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Oct 2019 17:32:04 -0700 (PDT) Date: Tue, 1 Oct 2019 20:32:03 -0400 From: Joel Fernandes To: "Viktor Rosendahl (BMW)" Cc: Steven Rostedt , Ingo Molnar , linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 1/4] ftrace: Implement fs notification for tracing_max_latency Message-ID: <20191002003203.GA161396@google.com> References: <20190920152219.12920-1-viktor.rosendahl@gmail.com> <20190920152219.12920-2-viktor.rosendahl@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190920152219.12920-2-viktor.rosendahl@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Some nits, but others looks good: On Fri, Sep 20, 2019 at 05:22:16PM +0200, Viktor Rosendahl (BMW) wrote: > This patch implements the feature that the tracing_max_latency file, > e.g. /sys/kernel/debug/tracing/tracing_max_latency will receive > notifications through the fsnotify framework when a new latency is > available. > > One particularly interesting use of this facility is when enabling > threshold tracing, through /sys/kernel/debug/tracing/tracing_thresh, > together with the preempt/irqsoff tracers. This makes it possible to > implement a user space program that can, with equal probability, > obtain traces of latencies that occur immediately after each other in > spite of the fact that the preempt/irqsoff tracers operate in overwrite > mode. > > This facility works with the hwlat, preempt/irqsoff, and wakeup > tracers. > > The tracers may call the latency_fsnotify() from places such as > __schedule() or do_idle(); this makes it impossible to call > queue_work() directly without risking a deadlock. The same would > happen with a softirq, kernel thread or tasklet. For this reason we > use the irq_work mechanism to call queue_work(). > > This patch creates a new workqueue. The reason for doing this is that > I wanted to use the WQ_UNBOUND and WQ_HIGHPRI flags. My thinking was > that WQ_UNBOUND might help with the latency in some important cases. > > If we use: > > queue_work(system_highpri_wq, &tr->fsnotify_work); > > then the work will (almost) always execute on the same CPU but if we are > unlucky that CPU could be too busy while there could be another CPU in > the system that would be able to process the work soon enough. > > queue_work_on() could be used to queue the work on another CPU but it > seems difficult to select the right CPU. > > Signed-off-by: Viktor Rosendahl (BMW) > --- > kernel/trace/trace.c | 75 +++++++++++++++++++++++++++++++++++++- > kernel/trace/trace.h | 18 +++++++++ > kernel/trace/trace_hwlat.c | 4 +- > 3 files changed, 94 insertions(+), 3 deletions(-) > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c > index 947ba433865f..2d2150bf0d42 100644 > --- a/kernel/trace/trace.c > +++ b/kernel/trace/trace.c > @@ -44,6 +44,9 @@ > #include > #include > #include > +#include > +#include > +#include > > #include "trace.h" > #include "trace_output.h" > @@ -1480,6 +1483,74 @@ static ssize_t trace_seq_to_buffer(struct trace_seq *s, void *buf, size_t cnt) > > unsigned long __read_mostly tracing_thresh; > > +#if (defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER)) && \ > + defined(CONFIG_FSNOTIFY) > + > +static const struct file_operations tracing_max_lat_fops; > +static struct workqueue_struct *fsnotify_wq; > + > +static void latency_fsnotify_workfn(struct work_struct *work) > +{ > + struct trace_array *tr = container_of(work, struct trace_array, > + fsnotify_work); > + fsnotify(tr->d_max_latency->d_inode, FS_MODIFY, > + tr->d_max_latency->d_inode, FSNOTIFY_EVENT_INODE, NULL, 0); > +} > + > +static void latency_fsnotify_workfn_irq(struct irq_work *iwork) > +{ > + struct trace_array *tr = container_of(iwork, struct trace_array, > + fsnotify_irqwork); > + queue_work(fsnotify_wq, &tr->fsnotify_work); > +} > + > +static void trace_create_maxlat_file(struct trace_array *tr, > + struct dentry *d_tracer) > +{ > + INIT_WORK(&tr->fsnotify_work, latency_fsnotify_workfn); > + init_irq_work(&tr->fsnotify_irqwork, latency_fsnotify_workfn_irq); > + tr->d_max_latency = trace_create_file("tracing_max_latency", 0644, > + d_tracer, &tr->max_latency, > + &tracing_max_lat_fops); > +} > + > +__init static int latency_fsnotify_init(void) > +{ > + fsnotify_wq = alloc_workqueue("tr_max_lat_wq", > + WQ_UNBOUND | WQ_HIGHPRI, 0); > + if (!fsnotify_wq) { > + pr_err("Unable to allocate tr_max_lat_wq\n"); > + return -ENOMEM; > + } > + return 0; > +} > + > +late_initcall_sync(latency_fsnotify_init); > + > +void latency_fsnotify(struct trace_array *tr) > +{ > + if (!fsnotify_wq) > + return; > + /* > + * We cannot call queue_work(&tr->fsnotify_work) from here because it's > + * possible that we are called from __schedule() or do_idle(), which > + * could cause a deadlock. > + */ > + irq_work_queue(&tr->fsnotify_irqwork); > +} > + > +/* > + * (defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER)) && \ > + * defined(CONFIG_FSNOTIFY) > + */ > +#else > + > +#define trace_create_maxlat_file(tr, d_tracer) \ > + trace_create_file("tracing_max_latency", 0644, d_tracer, \ > + &tr->max_latency, &tracing_max_lat_fops) I would forward declare tracing_max_lat_fops here as well like you are doing in the #if section. This has 2 advantages: 1. It keeps it consistent with the #if block. 2. It prevents future breakages where trace_create_maxlat_file() might be called before tracing_max_lat_fops is defined. > + > +#endif > + > #ifdef CONFIG_TRACER_MAX_TRACE > /* > * Copy the new maximum trace into the separate maximum-trace > @@ -1518,6 +1589,7 @@ __update_max_tr(struct trace_array *tr, struct task_struct *tsk, int cpu) > > /* record this tasks comm */ > tracing_record_cmdline(tsk); > + latency_fsnotify(tr); > } > > /** > @@ -8550,8 +8622,7 @@ init_tracer_tracefs(struct trace_array *tr, struct dentry *d_tracer) > create_trace_options_dir(tr); > > #if defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER) > - trace_create_file("tracing_max_latency", 0644, d_tracer, > - &tr->max_latency, &tracing_max_lat_fops); > + trace_create_maxlat_file(tr, d_tracer); > #endif > > if (ftrace_create_function_files(tr, d_tracer)) > diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h > index 005f08629b8b..4913ed1138aa 100644 > --- a/kernel/trace/trace.h > +++ b/kernel/trace/trace.h > @@ -16,6 +16,8 @@ > #include > #include > #include > +#include > +#include > > #ifdef CONFIG_FTRACE_SYSCALLS > #include /* For NR_SYSCALLS */ > @@ -264,6 +266,11 @@ struct trace_array { > #endif > #if defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER) > unsigned long max_latency; > +#ifdef CONFIG_FSNOTIFY > + struct dentry *d_max_latency; > + struct work_struct fsnotify_work; > + struct irq_work fsnotify_irqwork; > +#endif > #endif > struct trace_pid_list __rcu *filtered_pids; > /* > @@ -785,6 +792,17 @@ void update_max_tr_single(struct trace_array *tr, > struct task_struct *tsk, int cpu); > #endif /* CONFIG_TRACER_MAX_TRACE */ > > +#if (defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER)) && \ > + defined(CONFIG_FSNOTIFY) > + > +void latency_fsnotify(struct trace_array *tr); > + > +#else > + > +#define latency_fsnotify(tr) do { } while (0) Please define the NOOP as a function so that compiler checks the arguments. So: static void latency_fsnotify(struct trace_array *tr) { } Other than these nits, the patch looks fine to me. Reviewed-by: Joel Fernandes (Google) thanks, - Joel