From owner-freebsd-arch Thu Dec 20 13:40:24 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 06F4537B416; Thu, 20 Dec 2001 13:40:18 -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 <20011220214018.HXRO6450.rwcrmhc52.attbi.com@InterJet.elischer.org>; Thu, 20 Dec 2001 21:40:18 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA52968; Thu, 20 Dec 2001 13:29:20 -0800 (PST) Date: Thu, 20 Dec 2001 13:29:20 -0800 (PST) From: Julian Elischer To: John Baldwin Cc: Poul-Henning Kamp , Alfred Perlstein , arch@FreeBSD.org Subject: Re: Kernel stack size and stacking: do we have a problem ? In-Reply-To: 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, John Baldwin wrote: > > On 20-Dec-01 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. > > > > 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. > > > > 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. That may be true for a disk layer.. (in fact I doubt that it is true..) but it's not true for network stuff. In a disk layer, though, order isprobably not important. I would doubt that the operations would be synchronous. More likely asynchronous as PHK suggests. > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message