> 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… Thanks, -NGie _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
