On 21 Nov 2014, at 08:58, Marko Zec <z...@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 _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
