From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 08:25:54 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 742B0125; Fri, 21 Nov 2014 08:25:54 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 4FD0CBA2; Fri, 21 Nov 2014 08:25:54 +0000 (UTC) Received: from [10.0.1.18] (host86-132-108-5.range86-132.btcentralplus.com [86.132.108.5]) by cyrus.watson.org (Postfix) with ESMTPSA id 213B846B46; Fri, 21 Nov 2014 03:25:51 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: VIMAGE UDP memory leak fix From: "Robert N. M. Watson" In-Reply-To: <20141121002937.4f82daea@x23> Date: Fri, 21 Nov 2014 08:25:48 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141121002937.4f82daea@x23> To: Marko Zec X-Mailer: Apple Mail (2.1878.6) Cc: Craig Rodrigues , FreeBSD Net , "Bjoern A.Zeeb" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 08:25:54 -0000 On 20 Nov 2014, at 23:29, Marko Zec 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=