Date: Tue, 22 Feb 2005 14:59:32 -0800 From: Kris Kennaway <kris@obsecurity.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Julian Elischer <julian@elischer.org> Subject: Re: HEADSUP: Turn off cpu_idle_hlt on SMP for now on x86 Message-ID: <20050222225932.GA90362@xor.obsecurity.org> In-Reply-To: <200502221620.27992.jhb@FreeBSD.org> References: <200502111148.45976.jhb@FreeBSD.org> <200502221620.27992.jhb@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCG7lTWry0BWjoQKURAsA1AKDu+7tRT/PjM5cfKGW+vuO4KMU6XwCg5ENV cH+LjnG2bV85Sfh+49cZDHE= =m4EN -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050222225932.GA90362>