Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 4 Jan 2023 09:55:14 -0500
From:   Steven Rostedt <rostedt@goodmis.org>
To:     "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc:     John Stultz <jstultz@google.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Lingutla Chandrasekhar <clingutla@codeaurora.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        "Paul E. McKenney" <paulmck@kernel.org>,
        "Connor O'Brien" <connoro@google.com>, kernel-team@android.com,
        "J . Avila" <elavila@google.com>
Subject: Re: [PATCH] trace: Add trace points for tasklet entry/exit
Message-ID: <20230104095514.0481f1d8@gandalf.local.home>
In-Reply-To: <20230104232918.2791484c39ac54c59a7110f4@kernel.org>
References: <20230103185408.2874345-1-jstultz@google.com>
        <20230103151554.5c0a6c6f@gandalf.local.home>
        <20230104232918.2791484c39ac54c59a7110f4@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 4 Jan 2023 23:29:18 +0900
Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:

> >  # echo 'e:tasklet_info tasklet/tasklet_entry state=+8($tasklet):u64' > dynamic_events  
> 
> Hmm, what about saving 'state' and 'count' instead of 'tasklet'?
> 
> I have a question about the basic policy of making a new tracepoint.

The policy is to have something that is useful for analysis and debugging ;-)

> 
> Of course we can expand the event with eprobes as you said, but without
> eprobe, this 'tasklet' field of this event just exposing a kernel
> internal object address. That is useless in most cases. And also the
> offset (layout) in the kernel data structure can be changed by some
> debug options. We need an external tool to find correct offset (e.g.
> perf probe).
> 
> So my question is when adding a new event, whether it should expose a
> (address of) related data structure, or expose some value fields of
> the structure. IMHO, the basic policy is latter. Of course if the
> data structure is enough big and most of its fields are usually not
> interesting, it may be better to save the data structure itself.

This isn't unprecedented. Lots of tracepoints expose a pointer to a
structure. It's useful as that pointer becomes an identifier and can be
tracked.

The reason I prefer eprobe, is because it prevents anything from making it
into a ABI. We should try not exposing internally used fields if possible.
By exposing state and count, something can easily depend on those fields
as they are then exposed in the format file. Where as, eprobes is just
reading offsets of a pointer, and not something that can become ABI,
especially because the addresses may change with different compiled options.

-- Steve