Date: Sun, 15 Jul 2012 06:39:29 -0600 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Adrian Chadd <adrian@freebsd.org> Cc: Harm Weites <harm@weites.com>, freebsd-embedded@freebsd.org, Bernhard Schmidt <bschmidt@freebsd.org> Subject: Re: TP-Link wr1043nd out of swap space Message-ID: <1342355969.5473.6.camel@revolution.hippie.lan> In-Reply-To: <CAJ-Vmo=YTkVsn1eiGPpXewi_48BwDj=A72DwAWsUY_9X7=xC1w@mail.gmail.com> References: <1341745590.2740.17.camel@manbearpig.dynamic.weites.net> <201207081805.33574.bschmidt@freebsd.org> <1341841445.2540.10.camel@manbearpig.dynamic.weites.net> <CAOfEmZhPeEiiwUfn=5dt=vnkARV6551r%2BR_pSZrU4=07NiA8ow@mail.gmail.com> <1341849727.2540.11.camel@manbearpig.dynamic.weites.net> <CAOfEmZjLbqD941=wg7ReruhgY4u%2Bu0R7KkeDexFMUVQVssKdCQ@mail.gmail.com> <1342195983.2336.35.camel@manbearpig.dynamic.weites.net> <4B538596-937B-46F3-AF8F-17F34BE0C92D@bsdimp.com> <CAJ-Vmo=YTkVsn1eiGPpXewi_48BwDj=A72DwAWsUY_9X7=xC1w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2012-07-15 at 03:31 -0700, Adrian Chadd wrote: > Hi, > > I would really appreciate it if people (read; not me) would be able to > do the digging needed to get to the bottom of user/kernel memory > usage. > > I really need to focus on just the net80211/wifi stack side of things. > I'm going to focus on getting the ath(4) memory usage down over the > next few months so it remains feasible to run on 32MB platforms, as > those still ship. But I can't keep the rest of the kernel and userland > in check. > > Thanks, > > > Adrian I had to chase down "out of swap space" aborts on an ARM platform with 64MB not long ago, and I discovered that the kernel by default allocates 1/4 of available ram for vfs buffers (up to some limit, then it's 1/10 after that). I added "option NBUF=128" to our kernel config and that limited wired vfs buffer space to about 2MB, which seems much more reasonable for an embedded platform that does relatively little disk IO. I suspect the NBUF value could go even lower, but I'm also afraid that making it too low will lead to other problems; I don't really know enough to make an informed decision. So far the 128 value is working well in testing, but we haven't actually put any units in the field with that setting (I think we will pretty soon). -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1342355969.5473.6.camel>