Have you tried using ftrace? Seems like it would do the job. (http://lwn.net/Articles/365835/)
Tyler > I'm running some 16 core experiments with some simple OpenMP workloads > (specifically the STREAM memory benchmark). However, when I look at the > RIP > prints that scroll by in the console, I see 3 out of 16 cores stuck in > kernel space (all three at the same address: 0xffffffff81037eea). It > doesn't appear that these threads ever leave this address space according > to the prints. I've forced the affinity of the workload to run on all > cores > by using sched_setaffinity() before starting creating the checkpoint. So > I'm curious why in a very simple workload that's supposed to be running on > 16 threads, I'm getting these sticky threads. > > Is there some way to go about mapping this RIP back into some kind of > useful information about what is executing in the kernel at this address? > Is there some way to leverage the QEMU's GDB hooks to stop the world look > at what's going on inside the guest's execution? > > Thanks, > Paul > _______________________________________________ > http://www.marss86.org > Marss86-Devel mailing list > [email protected] > https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel > _______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
