Heads-up: Possible regression between 10.0-RELEASE and 10.1-BETA1 with '/ on ZFS' setup

[Glen Barber]

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 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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20141004/b8c858a3/attachment.sig>