Date: Thu, 20 Dec 2001 22:40:53 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Julian Elischer <julian@elischer.org> Cc: John Baldwin <jhb@FreeBSD.org>, arch@FreeBSD.org, Alfred Perlstein <bright@mu.org> Subject: Re: Kernel stack size and stacking: do we have a problem ? Message-ID: <3481.1008884453@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 20 Dec 2001 13:26:08 PST." <Pine.BSF.4.21.0112201322070.46573-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.21.0112201322070.46573-100000@InterJet.elischer.org>, Ju lian Elischer writes: >> >> Now, module 1 sends a request down through module 2 which takes the >> long path and consequently ends up being queued a module 3. We >> unwind/return back up through module 2 and module 1 issues another >> request which happens to take the short path through module 2 and >> consequently directly calls into module 3. > >NO, because once an item is queued, all requests will queue behind it >until the queue is drained again. > >What may happen in fact is that packet 2 will be queued and packet 1 >dequeued and processed, followed by packet 2 being dequeued and processed. >packet 3 may now proceed straight through.. Ahh, but now we hit the next problem: For stupid congestion reasons we have N requests queued, and then we happen to come around with N+1 while in an interrupt context and it gets to do all the work... We wouldn't want subject our interrupt contexts to risk that, would we ? -- 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?3481.1008884453>