From owner-freebsd-arch Thu Dec 20 13:34:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 1A57A37B417; Thu, 20 Dec 2001 13:33:56 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fBKLW3l03151; Thu, 20 Dec 2001 22:32:03 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: John Baldwin Cc: Alfred Perlstein , arch@FreeBSD.org, Julian Elischer Subject: Re: Kernel stack size and stacking: do we have a problem ? In-Reply-To: Your message of "Thu, 20 Dec 2001 13:21:24 PST." Date: Thu, 20 Dec 2001 22:32:03 +0100 Message-ID: <3149.1008883923@critter.freebsd.dk> From: Poul-Henning Kamp 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 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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message