svn commit: r289279 - in head/sys: kern vm

NGie Cooper yaneurabeya at gmail.com
Mon Nov 2 03:29:30 UTC 2015


> On Nov 1, 2015, at 19:20, Adrian Chadd <adrian.chadd at 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…

Thanks,
-NGie


More information about the svn-src-all mailing list