Date: Sun, 1 Nov 2015 19:29:28 -0800 From: NGie Cooper <yaneurabeya@gmail.com> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: 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: <DFF7EA25-64EA-44BB-BC0D-A84E52587B9D@gmail.com> In-Reply-To: <CAJ-Vmon2kKCMp6OemhW6CKUJ_a2iKz0pGg0zG2oqy2FuvLR73w@mail.gmail.com> References: <201510140210.t9E2A79H056595@repo.freebsd.org> <CAJ-Vmon2kKCMp6OemhW6CKUJ_a2iKz0pGg0zG2oqy2FuvLR73w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Nov 1, 2015, at 19:20, Adrian Chadd <adrian.chadd@gmail.com> wrote: >=20 > hiya jeff, >=20 > this broke low-memory, no-swap boards (eg MIPS.) >=20 > 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: >=20 >=20 > 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 >=20 > .. and it was just stuck in a loop trying to allocate them, failing, > and trying to allocate them again. >=20 > 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. >=20 > It's sufficient to just start the scp; it runs out of RAM within a > couple of seconds. >=20 > Any ideas? What happens if you change vfs.maxbufspace ? The reason that I=E2=80=99m noting is that (if I=E2=80=99m reading the = code correctly), it=E2=80=99s 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 =3D 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=E2=80=A6 it=E2=80=99s a bit high for low memory = platforms, i.e. platforms with <372MB of scratch space to play around = with I=E2=80=99m guessing=E2=80=A6 Thanks, -NGie=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DFF7EA25-64EA-44BB-BC0D-A84E52587B9D>