Intriguing. I will give this a shot. Thanks. On Fri, Mar 29, 2013 at 8:25 AM, <[email protected]> wrote:
> 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
