Hello, On Tue, 3 Dec 2024, Richard Biener wrote:
It doesn't I think. But the argument is "A is not implemented", let's do "B" instead. Yes, the paging issue is there with .eh_frame (but also with the stack, just more unlikely). And yes, you don't want to do even more work in NMI context. But I'd argue you want to do minimal work there only anyway, not even FP based unwinding - after a process switch you'd likely get TBL misses there. Not even considering RT ... So the solution is IMO to suspend the thread associated with the event from NMI and schedule a kernel worker thread (or whatever you have at your disposal these days for this), and exit from NMI context as fast as possible. Alternatively make sure the page we'd fault gets faulted in later (asynchonously) and give up on the unwind at that point (this is likely what we do when FP based unwind hits this?). You should get your .eh_frame faulted in after a few events then.
Exactly. And certainly eh_frame (or sframe) based stack traces will have a lower overhead than copying dozens pages of stack at each event to/from the trace buffers. Ciao, Michael.