From owner-freebsd-stable@FreeBSD.ORG Sat Oct 4 17:01:43 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 852057D7; Sat, 4 Oct 2014 17:01:42 +0000 (UTC) Date: Sat, 4 Oct 2014 13:01:37 -0400 From: Glen Barber To: Konstantin Belousov Subject: Re: Heads-up: Possible regression between 10.0-RELEASE and 10.1-BETA1 with '/ on ZFS' setup Message-ID: <20141004170137.GA1171@hub.FreeBSD.org> References: <20141004024011.GC1199@hub.FreeBSD.org> <64F0D761D09546C7B47DFAA1551500BE@multiplay.co.uk> <20141004031614.GD1199@hub.FreeBSD.org> <6618E7E0B17D41D09DB9B0160C2D4DF1@multiplay.co.uk> <9E274FD2D44943ED9F9C6057068C8CE0@multiplay.co.uk> <20141004151651.GG1199@hub.FreeBSD.org> <20141004160052.GR26076@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <20141004160052.GR26076@kib.kiev.ua> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Release Engineering Team , Steven Hartland , freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 17:01:43 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 04, 2014 at 07:00:53PM +0300, Konstantin Belousov wrote: > On Sat, Oct 04, 2014 at 11:16:51AM -0400, Glen Barber wrote: > > On Sat, Oct 04, 2014 at 04:03:39PM +0100, Steven Hartland wrote: > > > >>On Sat, Oct 04, 2014 at 03:51:39AM +0100, Steven Hartland wrote: > > > >>> > This has been a known issue on i386 since the switch to Clang s= ee UPDATING: > > > >>> 20121223: > > > >>> After switching to Clang as the default compiler some user= s of ZFS > > > >>> on i386 systems started to experience stack overflow kerne= l panics. > > > >>> Please consider using 'options KSTACK_PAGES=3D4' in such c= onfigurations. > > > >>> > In my experience your millage may vary but essentially without = 4 stack pages > > > >>> > all bets are off in terms of stability. > > >=20 > > > Oh and just looking at the code kern.kstack_pages is read only so won= t have > > > any effect, hence you will definitely need to set the kernel option a= s per > > > the UPDATING entry. > > >=20 > >=20 > > Indeed, it is readonly. I'm building kernel on the test VM, but may > > have to get the kernel built somewhere else from a non-ZFS VM, because > > the i386 VM with ZFS is unusable. > >=20 > > I'm not familiar with these parts of the kernel internals. What is the > > harm in making KSTACK_PAGES=3D4 the default in i386 GENERIC ? >=20 > KVA on i386 is limited, and increase of the stack pages means that > there is (significantly) less usermode threads can be created before > kernel gets out of KVA. Not to mention larger consumption of memory, > and need to find larger contig KVA region on the thread creation. >=20 > The cost of increasing stack size is significant, this is why the stack > is kept so small by all operating systems. Thank you for the explanation. 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? Glen --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUMCfxAAoJEAMUWKVHj+KTEjMP/RVC7PslgQaVrg0DzHsC+X1a 1iWeTXQR5vi2q88e0/DKzC4mG5Vl+Vfiiu23XFJsxprWNs3Wsz0jytzYZX3AU92m bWGHRThoH5GJHNdpTeMW6r9RT5gd2kRPUSWXyO44FIAsnN6I4YA2z29jXX5l/1Xd /YWHKJTAYOpPQeakiUJvjrAT9+Au/OYcy/oMbGYMhxLtR/rE89xaTw1HPT6wqLDE VJZv9m9N/f0at1KM/0x/ZZ7PIATfNV+KkBtdpVv32c0zm/jbzNR+jSJjfMZgtePt ebfBGysyQpZFZDtTbWOH+7sNvjLmZ8EwKbGYcw6Hlicyy0/zNBKanxER6mMPL/VN q5pIPrjEu6CmYgveu8VYDdGFe2ydZdZSDB34K6Aw0KuHyzaNSjDAMCTvkW6kbbcL RhH+dz+WjvPDKNxSaCyBKlZikvpw7JvTKHRvWokzr14BJRbmUzPdAYJo/Auecboz 4IjeEaaOEsOkAS8M/nQCQ78wZ6OVlQXp/7YlSNNega/xf6url5LEYFCqedYCd5ev 35dtWq/vTzURHNlL4v/9pnk3KiKo+lQVrjlDpOCWZYdH8iQtsdyCor1HVqaWY52E ODw0rmYcMzs+AQh0QV56PRKq0+NV2Z8WeabiJhxOfMmRBIW69ja4Pyc7sqw8pLBp AJreoUEPNVA9G5BhZSIm =wOmm -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT--