Date: Thu, 20 Dec 2001 23:17:05 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Alfred Perlstein <bright@mu.org> Cc: John Baldwin <jhb@FreeBSD.org>, Julian Elischer <julian@elischer.org>, arch@FreeBSD.org Subject: Re: Kernel stack size and stacking: do we have a problem ? Message-ID: <4236.1008886625@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 20 Dec 2001 16:12:30 CST." <20011220161230.L48837@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20011220161230.L48837@elvis.mu.org>, Alfred Perlstein writes: >* 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? The fact that we have nobody who would pick up the queued request and process it and that you would run into all sorts of locking, deadlock and starvation issues. >I know that >sleeping in certain VOPs isn't allowed, but maybe we could >somehow switch stacks temporarily via some sort of continuation >system... Some kind of "can I borrow a cup of kernel-stack" method might be an option, but I'd far rather just fail the VOP and tell the user to increase the kernel-stack size. As I said: The key to this question is that very few of the global changes to the VOP API have ever been completed entirely and consequently we should have a major good reason to start another one. -- 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?4236.1008886625>