Received-SPF: pass (google.com: domain of linux-kernel+bounces-143087-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Fri, 12 Apr 2024 09:37:24 -0700
From: Beau Belgrave <beaub@linux.microsoft.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mingo@redhat.com, acme@kernel.org, namhyung@kernel.org,
	rostedt@goodmis.org, mhiramat@kernel.org,
	mathieu.desnoyers@efficios.com, linux-kernel@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org,
	linux-perf-users@vger.kernel.org, mark.rutland@arm.com,
	alexander.shishkin@linux.intel.com, jolsa@kernel.org,
	irogers@google.com, adrian.hunter@intel.com, primiano@google.com,
	aahringo@redhat.com, dcook@linux.microsoft.com
Subject: Re: [RFC PATCH 0/4] perf: Correlating user process data to samples
Message-ID: <20240412163724.GB467-beaub@linux.microsoft.com>
References: <20240412001732.475-1-beaub@linux.microsoft.com>
 <20240412071245.GD30852@noisy.programming.kicks-ass.net>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240412071245.GD30852@noisy.programming.kicks-ass.net>

On Fri, Apr 12, 2024 at 09:12:45AM +0200, Peter Zijlstra wrote:
> 
> On Fri, Apr 12, 2024 at 12:17:28AM +0000, Beau Belgrave wrote:
> 
> > An idea flow would look like this:
> > User Task		Profile
> > do_work();		sample() -> IP + No activity
> > ...
> > set_activity(123);
> > ...
> > do_work();		sample() -> IP + activity (123)
> > ...
> > set_activity(124);
> > ...
> > do_work();		sample() -> IP + activity (124)
> 
> This, start with this, because until I saw this, I was utterly confused
> as to what the heck you were on about.
> 

Will do.

> I started by thinking we already have TID in samples so you can already
> associate back to user processes and got increasingly confused the
> further I went.
> 
> What you seem to want to do however is have some task-state included so
> you can see what the thread is doing.
> 

Yeah, there is typically an external context (not on the machine) that
wants to be tied to each sample. The context could be a simple integer,
UUID, or something else entirely. For OTel, this is a 16-byte array [1].

> Anyway, since we typically run stuff from NMI context, accessing user
> data is 'interesting'. As such I would really like to make this work
> depend on the call-graph rework that pushes all the user access bits
> into return-to-user.

Cool, I assume that's the SFRAME work? Are there pointers to work I
could look at and think about what a rebase looks like? Or do you have
someone in mind I should work with for this?

Thanks,
-Beau

1. https://www.w3.org/TR/trace-context/#version-format