From owner-freebsd-alpha Thu Sep 5 13: 3:19 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 BEFC237B400; Thu, 5 Sep 2002 13:03:16 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1CAF43E7B; Thu, 5 Sep 2002 13:03:15 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id QAA08226; Thu, 5 Sep 2002 16:03:15 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g85K2ip58532; Thu, 5 Sep 2002 16:02:44 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15735.47204.905352.900631@grasshopper.cs.duke.edu> Date: Thu, 5 Sep 2002 16:02:44 -0400 (EDT) To: John Baldwin Cc: freebsd-alpha@FreeBSD.org Subject: RE: ithread preemption In-Reply-To: References: <15735.44660.835003.901974@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 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? Perhaps we should only allow a small number of preemptions at any one time. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message