Date: Mon, 24 Nov 2008 18:46:02 -0500 From: gnn@freebsd.org To: Jeff Roberson <jroberson@jroberson.net> Cc: arch@freebsd.org Subject: Re: Limiting mbuf memory. Message-ID: <m23ahgads5.wl%gnn@neville-neil.com> In-Reply-To: <20081123213232.A971@desktop> References: <20081123213232.A971@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
At Sun, 23 Nov 2008 21:46:08 -1000 (HST), Jeff Roberson wrote: > > I'm developing a patch for an alternate memory layout for mbuf clusters > that relies on contigmalloc. Since this can fail, we'll still have to > retain the capability of allocating traditional clusters. I'll report > details on that later. I'm writing this email to address the issue of > resource accounting in mbufs. > > Presently we use a set of limits on individual zones or sizes of mbufs. > Standard mbufs, clusters, page size jumbos, 9k jumbos, and 16k jumbos. > Each is administered sperately. I think this is getting a bit unwieldy. > In the future, we may have even more sizes. This also introduces problems > because I will have two cluster zones do they each get their own limit? > > I would like to consolidate this into a single limit on the number of > pages in total allocated to networking. With perhaps some fractional > reservation for standard mbufs and clusters to make sure they aren't > overwhelmed by the larger buffers. > > This would be implemented by overriding the uma zone page allocator for > each of the mbuf zones with one that counts pages for all. Should we > reach the limit we'll block depending on the wait settings of the > requestor. The limit and sleep will probably be protected by a global > lock which won't be an issue because trips to the back end allocator are > infrequent and protected by their own global lock anyhow. > > How do people feel about this? To be clear this would eliminate: > > nmbclusters, nmbjumbop, nmbjumbo9, nmbjumbo16 and related config settings > and sysctls. They would be replaced by something like 'maxmbufbytes'. > Presently we place no limit on small mbufs. I could go either way on > this. It could be added to the limit or not. > I think this is a good idea with the caveat that I prefer the idea in paragraph 3 about reserving a bit of head room so we don't deadlock. A very common bug in the past was to run out of mbufs when using a lot of small UDP packets. Best, George
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m23ahgads5.wl%gnn>