On Fri, 24 Jan 2025 18:57:44 -0500 Steven Rostedt <rost...@goodmis.org> wrote:
> On Fri, 24 Jan 2025 14:50:11 -0800 > Josh Poimboeuf <jpoim...@kernel.org> wrote: > > > Hm, reading this again I'm wondering if you're actually proposing that > > the unwind happens on @prev after it gets rescheduled sometime in the > > future? Does that actually solve the issue? What if doesn't get > > rescheduled within a reasonable amount of time? > > Correct, it would be prev that would be doing the unwinding and not next. > But when prev is scheduled back onto the CPU. That way it's only blocking > itself. > > The use case that people were doing this with was measuring the time a task > is off the CPU. It can't get that time until the task schedules back > anyway. What the complaint was about was that it could be a very long > system call, with lots of sleeps and they couldn't do the processing. > > I can go back and ask, but I'm pretty sure doing the unwind when a task > comes back to the CPU would be sufficient. > Coming back from this. It would be fine if we could do the back trace when we come back from the scheduler, so it should not be an issue if the task even has to schedule again to fault in the sframe information. I was also wondering if the unwinder doesn't keep track of who requested the back trace, just that someone did. Then it would just take a single flag in the task struct to do the back trace. Return the "cookie" to the tracer that requested the back trace, and when you do the back trace, just call all callbacks with that cookie. Let the tracer decided if it wants to record the back trace or ignore it based on the cookie. That is, the tracers would need to keep track of the cookies that it cares about, as if there's other tracers asking for stack traces on tasks that this tracer doesn't care about it needs to handle being called when it doesn't care about the stack trace. That said, if you want to trace all tasks, you can just ignore the cookies and record the traces. -- Steve
