From owner-svn-src-head@freebsd.org Thu Nov 17 16:51:58 2016 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 B3D3EC47966; Thu, 17 Nov 2016 16:51:58 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (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 68764D02; Thu, 17 Nov 2016 16:51:57 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.16.0.17/8.16.0.17) with SMTP id uAHGh3gj028097; Thu, 17 Nov 2016 10:51:41 -0600 Received: from mh3.mail.rice.edu (mh3.mail.rice.edu [128.42.199.10]) by pp2.rice.edu with ESMTP id 26s1u3gbvx-1; Thu, 17 Nov 2016 10:51:41 -0600 X-Virus-Scanned: by amavis-2.7.0 at mh3.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh3.mail.rice.edu (Postfix) with ESMTPSA id 1085D4013D; Thu, 17 Nov 2016 10:51:41 -0600 (CST) Subject: Re: svn commit: r308691 - in head/sys: cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs fs/tmpfs kern vm To: Ruslan Bukin , Konstantin Belousov References: <201611151822.uAFIMoj2092581@repo.freebsd.org> <20161116133718.GA10251@bsdpad.com> <20161116165343.GX54029@kib.kiev.ua> <20161116165939.GA12498@bsdpad.com> <20161116175210.GA13203@bsdpad.com> Cc: Alan Cox , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Alan Cox Message-ID: <9047aad0-0713-5d7a-f92e-6f931642bb27@rice.edu> Date: Thu, 17 Nov 2016 10:51:40 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161116175210.GA13203@bsdpad.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611170292 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 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: Thu, 17 Nov 2016 16:51:58 -0000 On 11/16/2016 11:52, Ruslan Bukin wrote: > On Wed, Nov 16, 2016 at 04:59:39PM +0000, Ruslan Bukin wrote: >> On Wed, Nov 16, 2016 at 06:53:43PM +0200, Konstantin Belousov wrote: >>> On Wed, Nov 16, 2016 at 01:37:18PM +0000, Ruslan Bukin wrote: >>>> I have a panic with this on RISC-V. Any ideas ? >>> How did you checked that the revision you replied to, makes the probl= em ? >>> Note that the backtrace below is not reasonable. >> I reverted this commit like that and rebuilt kernel: >> git show 2fa36073055134deb2df39c7ca46264cfc313d77 | patch -p1 -R >> >> So the problem is reproducible on dual-core with 32mb mdroot. >> > I just found another interesting behavior: > depending on amount of physical memory : > 700m - panic > 800m - works fine > 1024m - panic I think that this behavior is not inconsistent with your report of the system crashing if you enabled two cores but not one. Specifically, changing the number of active cores will slightly affect the amount of memory that is allocated during initialization. There is nothing unusual in the sysctl output that you sent out. I have two suggestions. Try these in order. 1. r308691 reduced the size of struct vm_object. Try undoing the one snippet that reduced the vm object size and see if that makes a differenc= e. @@ -118,7 +118,6 @@ vm_ooffset_t backing_object_offset;/* Offset in backing object */ TAILQ_ENTRY(vm_object) pager_object_list; /* list of all objects of thi= s pager type */ LIST_HEAD(, vm_reserv) rvq; /* list of reservations */ - struct vm_radix cache; /* (o + f) root of the cache page radix trie */= void *handle; union { /* 2. I'd like to know if vm_page_scan_contig() is being called. Finally, to simply the situation a little, I would suggest that you disable superpage reservations in vmparam.h. You have no need for them.