Date: Fri, 21 Nov 2014 09:58:47 +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: <20141121095847.11601640@x23> In-Reply-To: <A4D676B3-6C50-47F7-8CFD-50B44FF4BE98@FreeBSD.org> References: <CAG=rPVehky00X4MuQQ-_Oe5ezWg52ZZrPASAh9GBy7baYv78CA@mail.gmail.com> <20141121002937.4f82daea@x23> <A4D676B3-6C50-47F7-8CFD-50B44FF4BE98@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 21 Nov 2014 08:25:48 +0000 "Robert N. M. Watson" <rwatson@FreeBSD.org> wrote: > > On 20 Nov 2014, at 23:29, Marko Zec <zec@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141121095847.11601640>