From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 22:18:17 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C87D16A545 for ; Tue, 22 Feb 2005 22:18:17 +0000 (GMT) Received: from mail27.sea5.speakeasy.net (mail27.sea5.speakeasy.net [69.17.117.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7DFA43D6D for ; Tue, 22 Feb 2005 22:18:16 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 20766 invoked from network); 22 Feb 2005 22:18:16 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 22 Feb 2005 22:18:16 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j1MMHvg9017494; Tue, 22 Feb 2005 17:18:09 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Tue, 22 Feb 2005 16:20:27 -0500 User-Agent: KMail/1.6.2 References: <200502111148.45976.jhb@FreeBSD.org> In-Reply-To: <200502111148.45976.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502221620.27992.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: jeffr@FreeBSD.org cc: Alan Cox cc: current@FreeBSD.org cc: Julian Elischer Subject: Re: HEADSUP: Turn off cpu_idle_hlt on SMP for now on x86 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 22:18:17 -0000 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. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org