Date: Sat, 4 Oct 2014 20:46:00 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Peter Wemm <peter@wemm.org> Cc: Glen Barber <gjb@freebsd.org>, Steven Hartland <smh@freebsd.org>, freebsd-stable@freebsd.org, FreeBSD Release Engineering Team <re@freebsd.org> Subject: Re: Heads-up: Possible regression between 10.0-RELEASE and 10.1-BETA1 with '/ on ZFS' setup Message-ID: <20141004174600.GU26076@kib.kiev.ua> In-Reply-To: <1684676.g0E56GkSvf@overcee.wemm.org> References: <20141004024011.GC1199@hub.FreeBSD.org> <20141004160052.GR26076@kib.kiev.ua> <20141004170137.GA1171@hub.FreeBSD.org> <1684676.g0E56GkSvf@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 04, 2014 at 10:03:48AM -0700, Peter Wemm wrote: > > If we cannot increase KSTACK_PAGES by default, do we have any > > alternative solution outside of suggesting to avoid using ZFS on i386 > > with more than one disk? > > When zfs creates its kthreads it can specify how much stack it needs. For > i386 it could ask for more for the zfs threads. Its not a good option but its > better than more stack for everything when it's already easy to run out > without zfs. This one probably happens in the init thread, not some of the zfs hord. Glen did not show the backtrace from ddb yet (I hope that ddb did not regressed and can step over double-fault boundary). We could specifically increment the init thread stack size as well, but I have no idea if normal VFS calls into ZFS are affected and cause overflow for the normal threads after the multitasking is fired.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141004174600.GU26076>