From owner-freebsd-arch Thu Dec 20 13:40:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id C56E437B419; Thu, 20 Dec 2001 13:40:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011220214008.HXNV6450.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 20 Dec 2001 21:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA52966; Thu, 20 Dec 2001 13:26:09 -0800 (PST) Date: Thu, 20 Dec 2001 13:26:08 -0800 (PST) From: Julian Elischer To: Poul-Henning Kamp Cc: John Baldwin , arch@FreeBSD.org, Alfred Perlstein Subject: Re: Kernel stack size and stacking: do we have a problem ? In-Reply-To: <2799.1008883049@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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