Date: Sat, 19 Nov 2016 13:47:43 -0600 From: Alan Cox <alc@rice.edu> To: Ruslan Bukin <ruslan.bukin@cl.cam.ac.uk> Cc: Konstantin Belousov <kostikbel@gmail.com>, Alan Cox <alc@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r308691 - in head/sys: cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs fs/tmpfs kern vm Message-ID: <31420999-26bb-c1fc-acee-8e2e20f42830@rice.edu> In-Reply-To: <20161118102235.GA40554@bsdpad.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31420999-26bb-c1fc-acee-8e2e20f42830>