Date: Thu, 20 Dec 2001 09:47:23 -0600 From: Alfred Perlstein <bright@mu.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: <20011220094723.B48837@elvis.mu.org> In-Reply-To: <600.1008837822@critter.freebsd.dk>; from phk@freebsd.org on Thu, Dec 20, 2001 at 09:43:42AM %2B0100 References: <600.1008837822@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
* Poul-Henning Kamp <phk@freebsd.org> [011220 04:46] 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. I think you're thinking way too hard about this, what would make sense is a near surefire way to catch stack overflow along with a panic message that was clear like "increase upages in kernel". Btw, Windows catches this and somehow assigns additional kernel stack pages to processes (or at least it seems). Do a search for "MinSp" or "MinSps". Lastly I would really avoid redesigning the VOPs however one suggestion would be to define an entry/exit function so that instead of having traditional stacking code like so: my_layer(void *foo) { if (mytest()) { NEXT_LAYER(foo); something; } return ERROR; } You could have: my_layer_entry(void *foo) { if (mytest()) return (foo, next_layer_ptr); else return ERROR; } my_layer_exit(void *foo) { something; } This would keep the stack at a near constant level at the expense of programming complexity. If you think about it though, it's quite like how network interrupts are handled, hardware queues the packets and then software runs after hardware returns. -Alfred 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?20011220094723.B48837>