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