Date: Fri, 21 Nov 2014 12:02:01 +0100 From: Marko Zec <zec@fer.hr> To: "Bjoern A. Zeeb" <bz@FreeBSD.org> Cc: Craig Rodrigues <rodrigc@freebsd.org>, FreeBSD Net <freebsd-net@freebsd.org>, "Robert N. M. Watson" <rwatson@FreeBSD.org> Subject: Re: VIMAGE UDP memory leak fix Message-ID: <20141121120201.6c77ea5b@x23> In-Reply-To: <9300CB5F-6140-4C49-B026-EB69B0E8B37E@FreeBSD.org> References: <CAG=rPVehky00X4MuQQ-_Oe5ezWg52ZZrPASAh9GBy7baYv78CA@mail.gmail.com> <20141121002937.4f82daea@x23> <A4D676B3-6C50-47F7-8CFD-50B44FF4BE98@FreeBSD.org> <9300CB5F-6140-4C49-B026-EB69B0E8B37E@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 21 Nov 2014 10:37:25 +0000 "Bjoern A. Zeeb" <bz@FreeBSD.org> wrote: > > On 21 Nov 2014, at 08:25 , 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... > > I had convinced myself for UDP many years ago that it was ok to > remove it. People have touched the code however so it’s definitively > worth re-checking again. > > For TCP we clearly cannot do it (yet, and couldn’t back then). But > TCP was the only of the few cases I had left unfixed back then. > Can’t remember what the others were (was like 3 or 4 of them; could > also be some of the fixes were indeed committed back then. Now that we've found ourselves in this discussion, I'm really becoming curious why exactly do we need UMA_ZONE_NOFREE for network stack zones at all? Admittedly, I always thought that the primary purpose of UMA_ZONE_NOFREE was to prevent uma_reclaim() from paging out _used_ zone pages, but reviewing the uma code reveals that this might not be the case, i.e. that NOFREE only prevents _unused_ pages to be freed by uma_reclaim(). Moreover, all uma_zalloc() calls as far as I can see are flagged as M_NOWAIT and are followed by checks for allocation failures, so that part seems to be covered. So, what's really the problem which UMA_ZONE_NOFREE flagging is supposed to solve these days? (you claim that we clearly need it for TCP - why)? Marko
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141121120201.6c77ea5b>