From owner-freebsd-alpha Thu Sep 5 13: 7: 6 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 3C03237B400 for ; Thu, 5 Sep 2002 13:07:03 -0700 (PDT) Received: from mail.speakeasy.net (mail17.speakeasy.net [216.254.0.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6C1F43E72 for ; Thu, 5 Sep 2002 13:07:02 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 7101 invoked from network); 5 Sep 2002 20:07:00 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail17.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 Sep 2002 20:07:00 -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 g85K70Bv012279; Thu, 5 Sep 2002 16:07:00 -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.47204.905352.900631@grasshopper.cs.duke.edu> Date: Thu, 05 Sep 2002 16:07:00 -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: > > > > > > 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. > > OK, so the interrupted thread will (eventually) return back to PAL. > > But, theoritically, under heavy load we could have lots of threads > preempted. And lots of interrupts pending which never returned to > PAL. Are we certain that this doesn't somehow violate assumptions made > by pal? Does any other OS work like this? Solaris doesn't run on alpha, but it also a bit different in its approach. I do wonder if there is a way we can violate an assumption in PAL due to migration though. That is, a thread could return to PAL on a different CPU than the one the interrupt was originally sent to. This might explain why only SMP has problems. -- 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