From owner-svn-src-all@freebsd.org Sat Nov 19 19:47:52 2016 Return-Path: Delivered-To: svn-src-all@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 ADC9FC4B551; Sat, 19 Nov 2016 19:47:52 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (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 797BD1ABD; Sat, 19 Nov 2016 19:47:51 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.16.0.17/8.16.0.17) with SMTP id uAJBZ0S6013943; Sat, 19 Nov 2016 13:47:44 -0600 Received: from mh3.mail.rice.edu (mh3.mail.rice.edu [128.42.199.10]) by pp1.rice.edu with ESMTP id 26tjv9r4qy-1; Sat, 19 Nov 2016 13:47:44 -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 C0EA840134; Sat, 19 Nov 2016 13:47:43 -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 References: <201611151822.uAFIMoj2092581@repo.freebsd.org> <20161116133718.GA10251@bsdpad.com> <20161116165343.GX54029@kib.kiev.ua> <20161116165939.GA12498@bsdpad.com> <20161116175210.GA13203@bsdpad.com> <9047aad0-0713-5d7a-f92e-6f931642bb27@rice.edu> <20161118102235.GA40554@bsdpad.com> Cc: Konstantin Belousov , Alan Cox , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Alan Cox Message-ID: <31420999-26bb-c1fc-acee-8e2e20f42830@rice.edu> Date: Sat, 19 Nov 2016 13:47:43 -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: <20161118102235.GA40554@bsdpad.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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-1611190142 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 19:47:52 -0000 On 11/18/2016 04:22, Ruslan Bukin wrote: > On Thu, Nov 17, 2016 at 10:51:40AM -0600, Alan Cox wrote: >> 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 problem ? >>>>> 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 difference. >> >> >> @@ -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 this 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. >> >> > I made another one merge from svn-head and problem disappeared for 700m,1024m of physical memory, but now I able to reproduce it with 900m of physical memory. > > Restoring 'struct vm_radix cache' in struct vm_object gives no behavior changes. > > Adding a panic() call to vm_page_scan_contig gives an original panic (so vm_page_scan_contig is not called), > it looks like size of function is changed and it unhides the original problem. > > Disable superpage reservations changes behavior and gives same panic on 1024m boot. I would still encourage you to commit a change disabling reservations in vmparam.h until support for superpages is added to the riscv pmap.