Date: Fri, 21 Nov 2014 09:05:17 +0000 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: Marko Zec <zec@fer.hr> 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: <36975BCB-1F45-4128-9FB6-004F07489E53@FreeBSD.org> In-Reply-To: <20141121095847.11601640@x23> References: <CAG=rPVehky00X4MuQQ-_Oe5ezWg52ZZrPASAh9GBy7baYv78CA@mail.gmail.com> <20141121002937.4f82daea@x23> <A4D676B3-6C50-47F7-8CFD-50B44FF4BE98@FreeBSD.org> <20141121095847.11601640@x23>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 Nov 2014, at 08:58, Marko Zec <zec@fer.hr> wrote: > Nevertheless, I'd prefer most of network stack UMA zones to be > de-virtualized, at least those which cannot cause interference between > VNETs, and that excludes syncache, reassembly, hostcache and the = likes. > De-virtualization doesn't require touching the UMA_ZONE_NOFREE flag, = so > doesn't affect non-VIMAGE builds. Any objections to that approach? 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). Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36975BCB-1F45-4128-9FB6-004F07489E53>