From owner-freebsd-arch Thu Dec 20 13:57:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 1749337B416 for ; Thu, 20 Dec 2001 13:57:15 -0800 (PST) Received: (qmail 29758 invoked from network); 20 Dec 2001 21:57:14 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Dec 2001 21:57:14 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3149.1008883923@critter.freebsd.dk> Date: Thu, 20 Dec 2001 13:56:57 -0800 (PST) From: John Baldwin To: Poul-Henning Kamp Subject: Re: Kernel stack size and stacking: do we have a problem ? Cc: Julian Elischer , arch@FreeBSD.org, Alfred Perlstein Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 20-Dec-01 Poul-Henning Kamp wrote: > In message , John Baldwin writes: > >>> Now the two requests have been reordered without any of the modules >>> having any hint of this. >>> >>> The obvious ways to fix this is to continue to queue once you queue >>> on a module (in other words: always queue if the queue is non-empty) >> >>Hmm, I was thinking that the original request would block when it queued the >>request, and would be woken up when the original request was completed by the >>worker thread. Thus, for each producer, only one item should be in the queue >>at a time (plus any sub events it may create), but that multiple producers >>may >>be putting events onto the queue handled by the worker thread. > > Ahh, but here you run into the zig-zag thing we two have talked about > earlier: what if I am running in an interrupt thread at this time ? > > This could be an incoming packet which triggers an outgoing response > or this could be a disk-write complete which triggers the write of > the other copy in the mirror. > > You cannot expect to be moving uniformly up (or down) the tree in > these kinds of layers so sleeping would be bad, and as far as my > intuition tells me, could lead to starvation and deadlock. Interrupts answer requests from the top half, they don't initiate requests on their own AFAIK. If an interrupt needs to initiate a request that it wants return state on, that's a bug I think. -- 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-arch" in the body of the message