From owner-freebsd-arch Thu Dec 20 14:21:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 5DA7337B41B for ; Thu, 20 Dec 2001 14:21:50 -0800 (PST) Received: (qmail 16617 invoked from network); 20 Dec 2001 22:21:49 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Dec 2001 22:21:49 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011220161230.L48837@elvis.mu.org> Date: Thu, 20 Dec 2001 14:21:32 -0800 (PST) From: John Baldwin To: Alfred Perlstein Subject: Re: Kernel stack size and stacking: do we have a problem ? Cc: arch@FreeBSD.org, Julian Elischer , Poul-Henning Kamp 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 20-Dec-01 Alfred Perlstein wrote: > * Poul-Henning Kamp [011220 16:08] wrote: >> >> B) We have no idea how to sanely fix VOP_ since it is synchronous. >> When I say "sanely" I'm referring to the fact that the VOP >> code is scary enough as it is and we don't want to make it even >> hairier, lest we loose the few filesystem hackers we have, not >> to mention the fact that we would probably never complete the >> conversion in the first place (see sys/vnode.h::IS_LOCKING_VFS() >> for precedent.) > > Wait, when you almost run out of stack what's stopping you from > queuing the vop data to a thread and then sleeping? I know that > sleeping in certain VOPs isn't allowed, but maybe we could > somehow switch stacks temporarily via some sort of continuation > system... That was basically my suggestion. Your original thread puts the request on a queue and blocks waiting for completion status. The worker thread grabs the event off the queue and finishes returning the completion status to the original thread. Note that if the worker kproc grows threads in a KSE-like manner when blocking, then you can end up chaining several threads if you ever get really deep nesting (although arguably a worker thread should just panic if it runs out of stack as we are probably stuck in an infinite recursion.) -- 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