From owner-freebsd-stable@FreeBSD.ORG Sat Oct 4 16:00:58 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6BAD7BE5; Sat, 4 Oct 2014 16:00:58 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CFF38392; Sat, 4 Oct 2014 16:00:57 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s94G0rjL035694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Oct 2014 19:00:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s94G0rjL035694 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s94G0r4N035693; Sat, 4 Oct 2014 19:00:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 4 Oct 2014 19:00:53 +0300 From: Konstantin Belousov To: Glen Barber Subject: Re: Heads-up: Possible regression between 10.0-RELEASE and 10.1-BETA1 with '/ on ZFS' setup Message-ID: <20141004160052.GR26076@kib.kiev.ua> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141004151651.GG1199@hub.FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home 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 16:00:58 -0000 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 see UPDATING: > > >>> 20121223: > > >>> After switching to Clang as the default compiler some users of ZFS > > >>> on i386 systems started to experience stack overflow kernel panics. > > >>> Please consider using 'options KSTACK_PAGES=4' in such configurations. > > >>> > In my experience your millage may vary but essentially without 4 stack pages > > >>> > all bets are off in terms of stability. > > > > 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 option as per > > the UPDATING entry. > > > > 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. > > I'm not familiar with these parts of the kernel internals. What is the > harm in making KSTACK_PAGES=4 the default in i386 GENERIC ? 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. The cost of increasing stack size is significant, this is why the stack is kept so small by all operating systems.