Date: Thu, 20 Dec 2001 22:32:03 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: John Baldwin <jhb@FreeBSD.org> Cc: Alfred Perlstein <bright@mu.org>, arch@FreeBSD.org, Julian Elischer <julian@elischer.org> Subject: Re: Kernel stack size and stacking: do we have a problem ? Message-ID: <3149.1008883923@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 20 Dec 2001 13:21:24 PST." <XFMail.011220132124.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <XFMail.011220132124.jhb@FreeBSD.org>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3149.1008883923>