Date: Wed, 27 Mar 2013 11:23:27 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-embedded@freebsd.org Subject: Re: FreeBSD on the AP121 (AR9330) Message-ID: <CAJ-VmokJ40LDF4WeuAENkZR89iStEmnTGkojeA6brSRkSKgJ1w@mail.gmail.com> In-Reply-To: <1364404612.36972.59.camel@revolution.hippie.lan> References: <CAJ-Vmom8sbMJvFn1ucGBSiptWtKPC0kE1Ss22Kj-WGVSkP_8ag@mail.gmail.com> <1364404612.36972.59.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27 March 2013 10:16, Ian Lepore <ian@freebsd.org> wrote: > For starters you might try disabling WITNESS and other things you can't > afford in a slimmed-down kernel. On the other hand, kernel bloat is Well, the only thing I can't really afford here is the -head debugging. But it doesn't actually slim down things significantly. I'll re-post the sizes later. [snip] > If the system isn't doing heavy IO, try "option NBUF=128" to seriously > slim down the amount of memory for buffers (by default it'll use 1/4 of > total ram up to 64MB). It would be nice to know more about the > implications of tweaking this number, but when I asked on a mailing list > once I didn't get much useful info. There's that; I think the problem here is deadlock if there's not enough buffers available. Guess that bug should be fixed. The other immediate thing is the umtx hash array. It's rather large (512) and it doesn't need to be. I haven't even started with the subsystem memory allocations yet either. They get even scarier. (And userland is doubly-scary on this platform. Sigh.) Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokJ40LDF4WeuAENkZR89iStEmnTGkojeA6brSRkSKgJ1w>