Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 1 Nov 2015 20:13:49 -0800
From:      Adrian Chadd <adrian.chadd@gmail.com>
To:        Jeff Roberson <jroberson@jroberson.net>
Cc:        NGie Cooper <yaneurabeya@gmail.com>, Jeff Roberson <jeff@freebsd.org>,  Mark Johnston <markj@freebsd.org>, Warner Losh <imp@bsdimp.com>, benno <benno@freebsd.org>,  "src-committers@freebsd.org" <src-committers@freebsd.org>,  "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>,  "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>
Subject:   Re: svn commit: r289279 - in head/sys: kern vm
Message-ID:  <CAJ-Vmonrh2r72QUE-ALd6O2VAM-_j%2BwHxP-NhN6UgvOaN4%2B6HA@mail.gmail.com>
In-Reply-To: <alpine.BSF.2.20.1511011803590.895@desktop>
References:  <201510140210.t9E2A79H056595@repo.freebsd.org> <CAJ-Vmon2kKCMp6OemhW6CKUJ_a2iKz0pGg0zG2oqy2FuvLR73w@mail.gmail.com> <DFF7EA25-64EA-44BB-BC0D-A84E52587B9D@gmail.com> <alpine.BSF.2.20.1511011803590.895@desktop>

next in thread | previous in thread | raw e-mail | index | archive | help
On 1 November 2015 at 20:05, Jeff Roberson <jroberson@jroberson.net> wrote:
> On Sun, 1 Nov 2015, NGie Cooper wrote:
>
>>
>>> On Nov 1, 2015, at 19:20, Adrian Chadd <adrian.chadd@gmail.com> wrote:
>>>
>>> hiya jeff,
>>>
>>> this broke low-memory, no-swap boards (eg MIPS.)
>>>
>>> On a MIPS board (carambola2) with 32MB of RAM, just scp'ing a kernel
>>> into the rootfs on USB hangs the system. After doing some digging, I
>>> found this:
>>>
>>>
>>> INTERNAL: Allocating one item from buf free cache(0x83fea7e0)
>>> uma_zalloc_arg: Bucketzone returned NULL
>>> INTERNAL: Allocating one item from buf free cache(0x83fea7e0)
>>> uma_zalloc_arg: Bucketzone returned NULL
>>>
>>> .. and it was just stuck in a loop trying to allocate them, failing,
>>> and trying to allocate them again.
>>>
>>> I'll see if I can reproduce it with a qemu emulator with sufficiently
>>> low RAM so you don't need a MIPS router to reproduce it.
>>>
>>> It's sufficient to just start the scp; it runs out of RAM within a
>>> couple of seconds.
>>>
>>> Any ideas?
>>
>>
>> What happens if you change vfs.maxbufspace ?
>>
>> The reason that I?m noting is that (if I?m reading the code correctly),
>> it?s now allocating 16 clean queues instead of 1 and each is up to
>> vfs.maxbufspace size, which is 256MB per queue based on this line:
>>
>> + clean_queues = MIN(howmany(maxbufspace, 256*1024*1024), CLEAN_QUEUES);
>>
>> The 256MB amount seems like it should be a tunable, as well as the
>> CLEAN_QUEUES #define? it?s a bit high for low memory platforms, i.e.
>> platforms with <372MB of scratch space to play around with I?m guessing?
>
>
> maxbufspace is still a global.  It just makes N queues for every 256MB of
> configured buffer cache size.
>
> We shouldn't be looping forever.  It should sleep and try to re-allocate.
> How many cpus are on the mips board?  We may need to implement something to
> directly flush the buf zone and disable the per-cpu caches when allocation
> fails.

It's a single CPU mips board (AR9331 SoC.)



-adrian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmonrh2r72QUE-ALd6O2VAM-_j%2BwHxP-NhN6UgvOaN4%2B6HA>