Date: Fri, 21 Nov 2014 10:45:38 +0100 From: Marko Zec <zec@fer.hr> To: "Robert N. M. Watson" <rwatson@FreeBSD.org> Cc: Craig Rodrigues <rodrigc@freebsd.org>, FreeBSD Net <freebsd-net@freebsd.org>, "Bjoern A.Zeeb" <bz@freebsd.org> Subject: Re: VIMAGE UDP memory leak fix Message-ID: <20141121104538.5eed0567@x23> In-Reply-To: <A8D54927-077E-4FFD-9EBE-1E486621F196@FreeBSD.org> References: <CAG=rPVehky00X4MuQQ-_Oe5ezWg52ZZrPASAh9GBy7baYv78CA@mail.gmail.com> <20141121002937.4f82daea@x23> <A4D676B3-6C50-47F7-8CFD-50B44FF4BE98@FreeBSD.org> <20141121095847.11601640@x23> <36975BCB-1F45-4128-9FB6-004F07489E53@FreeBSD.org> <A8D54927-077E-4FFD-9EBE-1E486621F196@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 21 Nov 2014 09:07:28 +0000 "Robert N. M. Watson" <rwatson@FreeBSD.org> wrote: > > On 21 Nov 2014, at 09:05, Robert N. M. Watson <rwatson@FreeBSD.ORG> > wrote: > > > To my mind, the only real concern is whether or not you lose access > > to resource allocation limits that would previously have been > > present. On the whole, we've tried to centralise resource > > limitations on kernel memory allocation in UMA, and it would be > > great if we could find a nice approach to implementing both > > per-vimage and per-system allocation limits. One thing I'd pondered > > in the past was whether we could move to a single zone, with its > > own limits/etc, but also the ability to pass an optional > > uma_resourcepool_t that allowed additional limits to be imposed > > based on some other criteria -- e.g., vimage membership. That > > strikes me as a somewhat complex proposal that would bring new > > performance/synchronisation concerns, so isn't necessarily > > something to act on. However, the upshot is that, although I do not > > oppose combining the zones, we should be aware that we're > > eliminating a form of resource partitioning between vimages that we > > may want to find some other solution for (ideally, an elegant one). > > And, to respond to your more general comment: I agree that a decision > about removing the NOFREE flag should be made independently of > choices about devirtualisation. The former probably should be sorted > out at this point, as eliminating NOFREE zones has more general > benefits to the kernel, but it would be nice not to depend on that to > resolve other problems. It could be that a few of us scratching our > heads for a few hours each can resolve whether NOFREE can now be > safely removed, in which case we should do so (and then allow quite a > lot of baking time before it ships in a release). The important thing here is not to loose the momentum and energy which Craig is putting in cleaning up VIMAGE, so if we take the route of eliminating the UMA_ZONE_NOFREE flag (or not), that should be decided with rough consensus and without too much delays, and without too much bikeshed re. what could be nice to have in some distant future and whatnot. The current goal is cleaning up VIMAGE and making it palatable for 11.0, without taking too much risk at breaking other things. I'm strongly opposed to even thinking aloud about any new VNET-related features or concepts until VIMAGE finally becomes enabled in /head. Marko
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141121104538.5eed0567>