Date: Thu, 20 Dec 2001 14:21:32 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Alfred Perlstein <bright@mu.org> Cc: arch@FreeBSD.org, Julian Elischer <julian@elischer.org>, Poul-Henning Kamp <phk@critter.freebsd.dk> Subject: Re: Kernel stack size and stacking: do we have a problem ? Message-ID: <XFMail.011220142132.jhb@FreeBSD.org> In-Reply-To: <20011220161230.L48837@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20-Dec-01 Alfred Perlstein wrote: > * Poul-Henning Kamp <phk@critter.freebsd.dk> [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 <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011220142132.jhb>