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
