Date: Thu, 20 Dec 2001 10:51:52 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Poul-Henning Kamp <phk@freebsd.org> Cc: arch@freebsd.org Subject: Re: Kernel stack size and stacking: do we have a problem ? Message-ID: <Pine.BSF.4.21.0112201048390.46573-100000@InterJet.elischer.org> In-Reply-To: <600.1008837822@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Netgraph has a bounding scheme that archie and I came up with, but it has not been committed yet. basically, in the -current version, the mbufs are passed with an itteration counter, and if you directly execute another module you increment it. If you queue the item you clear it to 0. After it reaches a limit of N the subsystem will queue it rather than try run the next layer directly. I have code to do that here and I've been thinking about checking it in.. On Thu, 20 Dec 2001, Poul-Henning Kamp wrote: > > 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 > 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?Pine.BSF.4.21.0112201048390.46573-100000>