From owner-freebsd-net@FreeBSD.ORG Thu Nov 20 23:29:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA6A1B05; Thu, 20 Nov 2014 23:29:40 +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 7E55CE4C; Thu, 20 Nov 2014 23:29:40 +0000 (UTC) Received: from x23 (31.147.126.92) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 21 Nov 2014 00:29:36 +0100 Date: Fri, 21 Nov 2014 00:29:37 +0100 From: Marko Zec To: Craig Rodrigues Subject: Re: VIMAGE UDP memory leak fix Message-ID: <20141121002937.4f82daea@x23> In-Reply-To: References: 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: [31.147.126.92] Cc: FreeBSD Net , "Bjoern A.Zeeb" , Robert Watson 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: Thu, 20 Nov 2014 23:29:41 -0000 On Thu, 20 Nov 2014 10:02:46 -0800 Craig Rodrigues wrote: > Hi, > > 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? One possible alternative is to de-virtualize V_udbinfo, V_udpcb_zone etc. which I have suggested a few times in the past but those proposals have been rejected based on expectations that one day our network stack may benefit from more parallelism of decoupled UMA zones for each VNET, though I'm not aware of further developments in that direction. The primary (and in many cases only) reason I have virtualized network stack zones was to simplify tracking of inter-VNET leaks. As bugs that caused such leaks seem to have been cleaned up some 7 years ago or so, I see no technical reason to maintain separate UMA zones for each VNET, especially not those which are size-limited to maxsockets global limit anyhow. Marko