On Sun, 1 Nov 2015, NGie Cooper wrote:
On Nov 1, 2015, at 19:20, Adrian Chadd <adrian.ch...@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.
Jeff
Thanks,
-NGie
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
