On Tue, 2005-02-22 at 17:59, Kris Kennaway wrote: > On Tue, Feb 22, 2005 at 04:20:27PM -0500, John Baldwin wrote: > > On Friday 11 February 2005 11:48 am, John Baldwin wrote: > > > Thus, my theory is that when the pinned thread was preempted and put back > > > on the run queue, the scheduler didn't IPI the CPU it was pinned to to wake > > > it up in case it was idle. The IPI is only needed if the CPUs are halted, > > > which is why I think turning the idle halt off might work as a workaround. > > > I don't know if ULE has this same issue, but I've cc'd Jeff and hopefully > > > he can look into it. > > > > Nevermind, I don't think cpu_idle_hlt will help (though it has seemed to help > > locally oddly enough). Presumably the CPU that the preempted thread owning > > the vm page queues lock would have run the pinned thread before going idle. > > In this case, that means that the thread must be pinned to CPU 0 which is > > running a make process that is just spinning. Unfortunately we currently > > don't have a good way of looking at the stack for an thread on another CPU. > > I'm running into this with deadlocks I'm seeing on a quad-cpu RELENG_5 > sparc machine. > > Unfortunately, I can't even dump because of yet more locking assertion > failures in the dump path (CAM, elsewhere). > > Kris The attached patch (hopefully ;-) fixes a few scheduler problems with both SMP and UP. The patch also adds an IPI to PREEMPT threads on other CPUs for i386. While I compiled every valid combination of SMP,PREEMPT,FULL_PREEMPT I did not have time to test all combinations. ( This needs a lot more testing - but I ran out of time) Please test and provide feedback. Thanks Stephan
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:29 UTC