svn commit: r286223 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Slawa Olhovchenkov]

On Mon, Aug 03, 2015 at 02:19:42PM +0300, Konstantin Belousov wrote:

> > The whole thing has missing the point.
> > 
> > Changing the default for the entire kernel just because the zfs compat 
> > wrappers can't be bothered requesting a suitable value is.. unfortunate.. 
> > particularly when it is in freebsd-provided code, not upstream zfs code.
> > 
> > Fix the kproc_kthread_add() calls in do_thread_create() and zvol_geom_run() 
> > instead.  Enforce a lower bound there for zfs threads instead of making the 
> > entire rest of the kernel use more memory.
> > 
> > eg: I'm thinking along these lines:
> > Index: cddl/compat/opensolaris/sys/proc.h
> > ====================================================
> > --- cddl/compat/opensolaris/sys/proc.h	(revision 286224)
> > +++ cddl/compat/opensolaris/sys/proc.h	(working copy)
> > @@ -77,6 +77,8 @@
> >  	ASSERT(state == TS_RUN);
> >  	ASSERT(pp == &p0);
> >  
> > +	if (stksize < 16384)
> > +		stksize = 16384;	/* Enforce lower bound on ZFS threads */
> >  	error = kproc_kthread_add(proc, arg, &zfsproc, &td, RFSTOPPED,
> >  	    stksize / PAGE_SIZE, "zfskern", "solthread %p", proc);
> >  	if (error == 0) {
> > 
> > 
> > Beware, some platforms have large pages (eg: ia64 in -stable has 8k, 16k or 
> > 32k pages, from memory).  Specifying an arbitrary number of pages in code 
> > that's supposed to be portable isn't a good idea.
> 
> This would not help. Issue is the size of the thread0 stack, which
> overflows in this case.
> 
> I looked at the possibility of making default kernel stack size
> configurable by a loader tunable, and the issue is that thread0 gets its
> stack set up too early (locore for i386, hammer_time() for amd64).  I.e.,
> it is possible to make the setting effective for all threads after thread0,
> but not for the one which causes the issue.
> 
> I do not want to modify ABI between loader and kernel to pass the parameter.

Parsing kenv by asm too complex?