Date: Thu, 20 Dec 2001 09:43:42 +0100 From: Poul-Henning Kamp <phk@freebsd.org> To: arch@freebsd.org Subject: Kernel stack size and stacking: do we have a problem ? Message-ID: <600.1008837822@critter.freebsd.dk>
next in thread | raw e-mail | index | archive | help
As most of you have probably heard, I'm working on a stacking disk I/O layer (http://freefall.freebsd.org/~phk/Geom). This is as far as I know, only the third freely stackable subsystem in the kernel, the first two being VFS/filesystems and netgraph. The problem with stacking layered systems is that the naïve and simple implementation, just calling into the layer below, has basically unbounded kernel stack usage. Fortunately for us, neither VFS nor netgraph has had too much use yet, so we have not been excessively bothered by people running out of kernel-stack. It is well documented how to avoid the unbounded stack usage for such setups: simply queue the requests at each "gadget" and run a scheduler but this no where near as simple nor as fast as the direct call. So I guess we need to ask our selves the following questions: 1. What do we do when people start to run out of kernel stack because they stack filesystems ? a) Tell them not to. b) Tell them to increase UPAGES. c) Increase default UPAGES. d) Redesign VFS/VOP to avoid the problem. 2. Do we in general want to incur the overhead of scheduling in stacking layers or does increasing the kernel stack as needed make more sense ? 3. Would it be possible to make kernel stack size a sysctl ? 4. Would it make sense to build an intelligent kernel-stack overflow handling into the kernel, rather than "handling" this with a panic ? It should be trivially simple to make a function called enough_stack() which would return false if we were in the danger zone. This function could then be used to fail intelligently at strategic high-risk points in the kernel: int somefunction(...) { ... if (!enough_stack()) return (ENOMEM); ... } Think about it... -- 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?600.1008837822>