From owner-freebsd-alpha Thu Sep 5 12:35:39 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBD2E37B400 for ; Thu, 5 Sep 2002 12:35:36 -0700 (PDT) Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74BA743E75 for ; Thu, 5 Sep 2002 12:35:36 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 4282 invoked from network); 5 Sep 2002 19:35:35 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 Sep 2002 19:35:35 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.5/8.12.5) with ESMTP id g85JZXBv012169; Thu, 5 Sep 2002 15:35:34 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <15735.44660.835003.901974@grasshopper.cs.duke.edu> Date: Thu, 05 Sep 2002 15:35:33 -0400 (EDT) From: John Baldwin To: Andrew Gallatin Subject: RE: ithread preemption Cc: freebsd-alpha@FreeBSD.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 05-Sep-2002 Andrew Gallatin wrote: > > John Baldwin writes: > > > > On 05-Sep-2002 Andrew Gallatin wrote: > > > > > > I've forgotten -- What are the symptoms of ithread preemption causing > > > troubles on alpha? > > > > Hangs on SMP under load. > > > > > I have one (probably dumb) idea: Is the ithread preemption code > > > guaranteed to switch back to the preempted thread when the ithread > > > completes or blocks? And continue through to the end of the interrupt > > > dispatch code, returning back to the palcode? > > > > It is not guaranteed to do that. > > What keeps you from (eventually) running out of kernel stack space > then, as the interrupts keep coming in? The thread that received the interrupt stays at the high IPL until it returns. When you switch to another thread you are on another stack and you can take an interrupt ok. When we switch back to an interrupted thread, it executes at the raised IPL until it returns back to the PAL code. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message