Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 4 Oct 2014 17:15:30 -0400
From:      Glen Barber <gjb@FreeBSD.org>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        FreeBSD Release Engineering Team <re@freebsd.org>, Steven Hartland <smh@freebsd.org>, freebsd-stable@freebsd.org, Peter Wemm <peter@wemm.org>
Subject:   Re: Heads-up: Possible regression between 10.0-RELEASE and 10.1-BETA1 with '/ on ZFS' setup
Message-ID:  <20141004211530.GB1171@hub.FreeBSD.org>
In-Reply-To: <20141004174600.GU26076@kib.kiev.ua>
References:  <20141004024011.GC1199@hub.FreeBSD.org> <20141004160052.GR26076@kib.kiev.ua> <20141004170137.GA1171@hub.FreeBSD.org> <1684676.g0E56GkSvf@overcee.wemm.org> <20141004174600.GU26076@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help

--jq0ap7NbKX2Kqbes
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Oct 04, 2014 at 08:46:00PM +0300, Konstantin Belousov wrote:
> 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?
> >=20
> > When zfs creates its kthreads it can specify how much stack it needs.  =
For=20
> > i386 it could ask for more for the zfs threads.  Its not a good option =
but its=20
> > better than more stack for everything when it's already easy to run out=
=20
> > without zfs.
>=20
> 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).
>=20
> 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 overfl=
ow
> for the normal threads after the multitasking is fired.

As soon as I get the kernel built with debugging support, I'll be able
to get the backtrace.  This, however, is proving to be non-trivial.

Glen


--jq0ap7NbKX2Kqbes
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJUMGNyAAoJEAMUWKVHj+KTJtkP/R8xBLxZaTUQG6tNA5awl6PT
ZOj9T/Qmkz9m9dO2FaGu0VbAqyzRBVjsLkIYmfIIw62r0NvWtEgMmKN3hiypLUQy
qm1xgaxD0sVbJ2IgSW9S0EpmvKDlLmLPqaGLb0vpx5BiIxtC7OoPwOk3ieA9qGle
WLK+sPoRM2wENatXwgyCNqnRzjzxOg1XCYnYyL8h56CtB1egb+a6cqJBbqbsYMv3
uzpMrSyaeC6eOMG1MgsfuV8rJ7m7wi0peEg0i/ndqwxNBI/HNVHVLY30LxZY6mCp
BNqp9OCvHAmt/DCVuIrvH16akp3iypmdsX0tH5MORNqtSOPIbVOsz/J6ZOOWuCqb
WLnFWTBJqnqzMGRLGkYPAlDVGPd6vsCXPX3gMgpuFHzx4VG+Tekci5NyYYi4+O/j
tPBTa703yQ8qRSw8ScI0kOEd1+tIC8kzkKkK5aAFGfUHRQsSGl53/JNuC3P2c2at
RhSDY/84OBC82LyZmXXY+Jvq+n+3eDveKOLAeg2Ps6mc2i/ONq2w4Ck0p3G22gnC
eYvowd6+Q/CFq/06BA4ms7mrbtB36NgGkgUgmeeWv14hJ79FV1W9XxX2zy0a9tyZ
QH8IiileuvzfqXrQ5RV+jvyP8gqyOoxqu//cJcdwM0IMnz8Br2adRCDyMgT4RJSx
A9esWjZv7ZduNgJegSLG
=P/OQ
-----END PGP SIGNATURE-----

--jq0ap7NbKX2Kqbes--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141004211530.GB1171>