Date: Thu, 20 Dec 2001 13:26:08 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> 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: <Pine.BSF.4.21.0112201322070.46573-100000@InterJet.elischer.org> In-Reply-To: <2799.1008883049@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 20 Dec 2001, Poul-Henning Kamp wrote: > > Julian, doesn't this give you an ordering issue ? > > Imagine this setup > > (lots of stuff) > | > module 1 > | > module 2 > | > module 3 > > With the added information that the path through module 2 can be very > short or very long, depending on the packet contents. meaning it uses more stack? (I'm assuming that that is what you mean) > > 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.. > > 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) I do.... It's a requirement because of the nature of rteh read/write lock on each node. Exclusive (writer) locks need to ensure that they are not bypassed by readers while they are queued, or they may NEVER get to run.. > > > -- > 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?Pine.BSF.4.21.0112201322070.46573-100000>