On Fri, 21 Nov 2014 08:25:48 +0000 "Robert N. M. Watson" <rwat...@freebsd.org> wrote:
> > On 20 Nov 2014, at 23:29, Marko Zec <z...@fer.hr> wrote: > > >> Can folks take a look at this? > >> > >> https://reviews.freebsd.org/D1201 > > > > All UMA zones used in the network stack have been marked as > > UMA_ZONE_NOFREE for ages, probably for a reason, so perhaps it might > > not hurt to provide more insight why and how it suddenly became > > safe to remove that flag? > > Historically, this was (if I recall) a property of the way data was > exported for netstat, which depended on memory stability of various > data types. We have worked quite hard to remove the causes of those > sorts of dependencies by introducing stronger reference and memory > ownership models throughout the stack -- in the case of inpcbs, for > example, we introduced a true reference model during the > multiprocessing scalability work (which, it should be pointed out, > was enormously painful and took years to shake the bugs out of due to > complexity/subtlety). It may be that it is now safe to remove > UMA_ZONE_NOFREE for some of the types where it was previously > required -- but it's definitely something you want to do > intentionally and in the context of a careful analysis to convince > yourself that all the causes have been addressed. A fair amount of > stress testing in low-memory conditions wouldn't hurt either... If data stability for userland export was the only factor mandating UMA_ZONE_NOFREE flagging then indeed it may be safe to remove that flag, since the VNET / prison referencing model guarantees that no VNET teardown can commence as long as there are processes, sockets or ifnets attached to a particular VNET. But as you said that change would affect both VIMAGE and non-VIMAGE builds, so extensive testing would be warranted here. 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? Marko _______________________________________________ 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"
