Date: Thu, 20 Dec 2001 23:06:16 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: John Baldwin <jhb@FreeBSD.org> Cc: Julian Elischer <julian@elischer.org>, arch@FreeBSD.org, Alfred Perlstein <bright@mu.org> Subject: Re: Kernel stack size and stacking: do we have a problem ? Message-ID: <3954.1008885976@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 20 Dec 2001 13:56:57 PST." <XFMail.011220135657.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <XFMail.011220135657.jhb@FreeBSD.org>, John Baldwin writes: >Interrupts answer requests from the top half, they don't initiate requests on >their own AFAIK. If an interrupt needs to initiate a request that it wants >return state on, that's a bug I think. Ahh, I see a misunderstanding here: in VOP_ you have return state because the calls are synchronous, but netgraph and Geom are both asynchronous by design. The fact that VOP_ is synchrnous is also what makes it so hard to fix, and why I was kind of hoping for people to say "Don't worry about kernel stack, RAM is dirt cheap!" :-) Anyway, I guess the conclusion on this thread will be: A) We should probably implement int enough_stack() and apply it in some strategic places so we can fail gracely rather than panic when we run out of kernel stack. 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.) C) Variant size kernel stacks are probably not worth the bother, but sysctl variable kernel stacks might be a good investment. C) Netgraph and Geom will use scheduling, possibly with a direct call optimization to avoid the issue. Julian hybrid scheme could possibly be adapted to Geom, if it can be made to maintain ordering (think: softupdates). Thanks for your input gentlemen. -- 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?3954.1008885976>