From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 08:58:48 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 DBE3BE20; Fri, 21 Nov 2014 08:58:48 +0000 (UTC) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E98AF0B; Fri, 21 Nov 2014 08:58:47 +0000 (UTC) Received: from x23 (161.53.63.210) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 21 Nov 2014 09:58:45 +0100 Date: Fri, 21 Nov 2014 09:58:47 +0100 From: Marko Zec To: "Robert N. M. Watson" Subject: Re: VIMAGE UDP memory leak fix Message-ID: <20141121095847.11601640@x23> In-Reply-To: References: <20141121002937.4f82daea@x23> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [161.53.63.210] 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:58:49 -0000 On Fri, 21 Nov 2014 08:25:48 +0000 "Robert N. M. Watson" wrote: > > On 20 Nov 2014, at 23:29, Marko Zec 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