Date: Thu, 05 Sep 2002 16:07:00 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: freebsd-alpha@FreeBSD.org Subject: RE: ithread preemption Message-ID: <XFMail.20020905160700.jhb@FreeBSD.org> In-Reply-To: <15735.47204.905352.900631@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020905160700.jhb>