On Mon, 28 Apr 2025 17:29:53 -0700 Namhyung Kim <[email protected]> wrote:
> Thing is that the kernel doesn't know the relationship between events. > For example, if I run this command on a machine with 100 CPUs: > > $ perf record -e cycles,instructions -- $MYPROG > > it would open 200 events and they don't know each other. Later other > process can start a new perf profiling for the same task. IIUC there's > no way to identify which one is related in the kernel. > > So I think we need a way to share some informaiton for those 200 events > and then emits deferred callchain records with the shared info. Hmm, I'm thinking of creating an internal perf descriptor that would join events by who created them. That is, the first event created will take the thread leader (pid of the task) and check if an entity exists for it. If one doesn't exist it will create it and add itself to that event if it has a deferred trace attribute set. If it already exists, it will just add itself to it. This deferred descriptor will register itself with the deferred unwinder like ftrace does (one per process), and then use it to defer callbacks. When the callback happens, it will look for the thread event or CPU event that matches the current thread or current CPU and record the backtrace there. > > > > > It could use the cookie method that ftrace uses, where the request gets a > > cookie, and can be recorded to the perf event in the interrupt. Then the > > callchain would record the cookie along with the stack trace, and then perf > > tool could just match up the kernel stacks with their cookies to the user > > stack with its cookie. > > Yep, but the kernel should know which events (or ring buffer) it should > emit the deferred callchains. I don't think it needs to include the > cookie in the perf data, but it can be used to find which event or ring > buffer for the session is related to this request. Let me see if my suggestion would work or not. I'll try it out and see what happens. And post patches later. -- Steve
