Date: Fri, 21 Nov 2014 10:37:25 +0000 From: "Bjoern A. Zeeb" <bz@FreeBSD.org> To: "Robert N. M. Watson" <rwatson@FreeBSD.org> Cc: Craig Rodrigues <rodrigc@freebsd.org>, FreeBSD Net <freebsd-net@freebsd.org>, Marko Zec <zec@fer.hr> Subject: Re: VIMAGE UDP memory leak fix Message-ID: <9300CB5F-6140-4C49-B026-EB69B0E8B37E@FreeBSD.org> 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 21 Nov 2014, at 08:25 , Robert N. M. Watson <rwatson@FreeBSD.org> = wrote: >=20 > On 20 Nov 2014, at 23:29, Marko Zec <zec@fer.hr> wrote: >=20 >>> 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? >=20 > 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... I had convinced myself for UDP many years ago that it was ok to remove = it. People have touched the code however so it=92s definitively worth = re-checking again. For TCP we clearly cannot do it (yet, and couldn=92t back then). But = TCP was the only of the few cases I had left unfixed back then. Can=92t = remember what the others were (was like 3 or 4 of them; could also be = some of the fixes were indeed committed back then. =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9300CB5F-6140-4C49-B026-EB69B0E8B37E>