From owner-svn-src-head@freebsd.org Tue Aug 4 20:24:18 2015 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 211049B30E9; Tue, 4 Aug 2015 20:24:18 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CCDA21CD2; Tue, 4 Aug 2015 20:24:17 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1ZMikt-0005RD-Ff; Tue, 04 Aug 2015 23:24:11 +0300 Date: Tue, 4 Aug 2015 23:24:11 +0300 From: Slawa Olhovchenkov To: Steven Hartland Cc: Warner Losh , src-committers@freebsd.org, Peter Wemm , svn-src-all@freebsd.org, svn-src-head@freebsd.org, Konstantin Belousov , Julian Elischer Subject: Re: svn commit: r286223 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs Message-ID: <20150804202411.GD8792@zxy.spb.ru> References: <2757800.HIDNx1G49O@overcee.wemm.org> <20150803111942.GB2072@kib.kiev.ua> <55BF557B.60009@multiplay.co.uk> <20150803120359.GC2072@kib.kiev.ua> <55BFC296.5050402@freebsd.org> <20150803194412.GC8792@zxy.spb.ru> <55C07826.9070002@multiplay.co.uk> <20150804161448.GC24698@zxy.spb.ru> <55C11B5F.2080007@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C11B5F.2080007@multiplay.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 20:24:18 -0000 On Tue, Aug 04, 2015 at 09:06:55PM +0100, Steven Hartland wrote: > > > On 04/08/2015 17:14, Slawa Olhovchenkov wrote: > > On Tue, Aug 04, 2015 at 09:30:30AM +0100, Steven Hartland wrote: > > > >> > >> On 03/08/2015 21:48, Warner Losh wrote: > >>>> On Aug 3, 2015, at 1:44 PM, Slawa Olhovchenkov wrote: > >>>> > >>>> On Tue, Aug 04, 2015 at 03:35:50AM +0800, Julian Elischer wrote: > >>>> > >>>>> On 8/3/15 8:03 PM, Konstantin Belousov wrote: > >>>>>> On Mon, Aug 03, 2015 at 12:50:19PM +0100, Steven Hartland wrote: > >>>>>>> For this change I don't want to get into fixing the thread0 stack size, > >>>>>>> which can be done later, just > >>>>>>> to provide a reasonable warning to the user that smaller values could > >>>>>>> cause a panic. > >>>>>> Hmm, is it limited to the thread0 only ? I.e., would only increasing > >>>>>> the initial thread stack size be enough to boot the kernel ? The zfs > >>>>>> threads do request larger stack size, I know this. > >>>>>> > >>>>>> Can somebody test the following patch in the i386 configuration which > >>>>>> does not boot ? > >>>>> I think this is a reasonable thing to do. Thread0 (and proc0) are special. > >>>>> I don't see why giving it a specially sized stack would be a problem. > >>>> This is always do for ARM. > >>>> May be need increase stack size for Thread0 on ARM too? > >>> Seems reasonable. There should be a MI way of doing this, but all the code and defines are buried in MD files, so each architecture needs some love to make this a reality. > >>> > >>> Warner > >> In the mean time are people happier with > >> https://reviews.freebsd.org/D3279 or should I just leave it using the > >> #define until someone has time to work on a full solution? > > Checking by #ifdef you check only parametr at time of building zfs.ko, > > checking variable you check actual value. > > May be check thread stack best if only for current tread. > Not sure I follow you as its not a #ifdef check its straight if in the > new version i.e. > if (kstack_pages < ZFS_MIN_KSTACK_PAGES) { This check checked how actual kernel compile vs how compile zfs.ko. Remeber that kenel may be compiled independed from modules? > Just in case you didn't notice kib committed a fix for i386 thread0 in > r286288 so this may not be needed at all any more which is good news :) If I understund kib fix (and you about ZFS stack requirements) you need check curthread->td_kstack_pages (for case old, unfixed kerenel, depended from KSTACK_PAGES in Thread0). I.e. for all cases: - unfixed kernel with KSTACK_PAGES < 4 - unfixed kernel with KSTACK_PAGES >= 4 - fixed kernel with KSTACK_PAGES < 4 - fixed kernel with KSTACK_PAGES >= 4 - compiling zfs.ko separately from kernel with different KSTACK_PAGES - using zfs.ko with old kernel checking curthread->td_kstack_pages is right way (or, may be curthread->td_kstack_pages*PAGE_SIZE -- I am not cleanly understund what need to check -- size in bytes or size in pages). Checking KSTACK_PAGES by ifdef can produce vrong result.