From owner-freebsd-stable@FreeBSD.ORG Sat Oct 4 17:03:50 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A50578E2; Sat, 4 Oct 2014 17:03:50 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [192.203.228.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8211EB64; Sat, 4 Oct 2014 17:03:49 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 26210773; Sat, 4 Oct 2014 10:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1412442229; bh=nKuymHjAYsf1J/ntFlJfL9c+qLVVDGRRH6BBRlG0Tz0=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=MSG8p6vlARyjIoWzmudc3CzONeF2D5nCrgZlac7HlKxRMLLdbAI2DIsjESM4q+WNC KJVn1O6HMtUEj4YUf68xibc3OU9pKZG8lBxiNpn2+53xVCMxA1nF2u3l8cgYpEr2yR 52yv4UBFH31/fQl3VqmAjPRPYrdyocPmkW7z1ZEU= From: Peter Wemm To: freebsd-stable@freebsd.org Subject: Re: Heads-up: Possible regression between 10.0-RELEASE and 10.1-BETA1 with '/ on ZFS' setup Date: Sat, 04 Oct 2014 10:03:48 -0700 Message-ID: <1684676.g0E56GkSvf@overcee.wemm.org> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: <20141004170137.GA1171@hub.FreeBSD.org> References: <20141004024011.GC1199@hub.FreeBSD.org> <20141004160052.GR26076@kib.kiev.ua> <20141004170137.GA1171@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5290465.5yLRQROi4a"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: Konstantin Belousov , Glen Barber , Steven Hartland , FreeBSD Release Engineering Team , 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:03:50 -0000 --nextPart5290465.5yLRQROi4a Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Saturday, October 04, 2014 01:01:37 PM Glen Barber wrote: > 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 wro= te: > > > > >>> > This has been a known issue on i386 since the switch to C= lang=20 see UPDATING: > > > > >>> 20121223: > > > > >>> After switching to Clang as the default compiler som= e users > > > > >>> of ZFS > > > > >>> on i386 systems started to experience stack overflow= kernel > > > > >>> panics. > > > > >>> Please consider using 'options KSTACK_PAGES=3D4' in = such > > > > >>> configurations. > > > > >>> >=20 > > > > >>> > In my experience your millage may vary but essentially wi= thout 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 wont > > > > have > > > > any effect, hence you will definitely need to set the kernel op= tion as > > > > per > > > > the UPDATING entry. > > >=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, be= cause > > > 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 befor= e > > kernel gets out of KVA. Not to mention larger consumption of memor= y, > > 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 s= tack > > is kept so small by all operating systems. >=20 > Thank you for the explanation. >=20 > 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=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. =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart5290465.5yLRQROi4a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJUMCh0AAoJEDXWlwnsgJ4E9eIH/R5R8oc4S3gDQylf2LbNrX49 7p6TE2vpVkm3BMi2kYYlYel0Oen7Dy1RXqclwQdukn6vrhW0acFBUbxyH2LE36Mu yQZHMM1ZMvV6IrI5TV1C6tNHyIz5PddESBj47+75fd14ykazeivvgiWVLVCX7PJS fLZP1YTFAzwCigNivTUIv2pLEtfM1/MdlF/49f4XHNkt0rzRik/4PFOF2JAO6YkP 7v6u+fFCmy+dsu85L5gsLD/z8SIdhHU3VEuEjMIXrbzHkANvw41oUr7kK6gzqOCi nNcq/UyflsWCwwKd/JcCXuCdgNRaf1Z04b/1cfYRW0D3BjRWpE2gKI0VPeXPjI0= =PYk5 -----END PGP SIGNATURE----- --nextPart5290465.5yLRQROi4a--