From owner-freebsd-net@FreeBSD.ORG Fri Nov 21 09:05:26 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 7B743FE7; Fri, 21 Nov 2014 09:05:26 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 55E50FD6; Fri, 21 Nov 2014 09:05:26 +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 7478646B46; Fri, 21 Nov 2014 04:05:24 -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: <20141121095847.11601640@x23> Date: Fri, 21 Nov 2014 09:05:17 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <36975BCB-1F45-4128-9FB6-004F07489E53@FreeBSD.org> References: <20141121002937.4f82daea@x23> <20141121095847.11601640@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 09:05:26 -0000 On 21 Nov 2014, at 08:58, Marko Zec wrote: > 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? To my mind, the only real concern is whether or not you lose access to = resource allocation limits that would previously have been present. On = the whole, we've tried to centralise resource limitations on kernel = memory allocation in UMA, and it would be great if we could find a nice = approach to implementing both per-vimage and per-system allocation = limits. One thing I'd pondered in the past was whether we could move to = a single zone, with its own limits/etc, but also the ability to pass an = optional uma_resourcepool_t that allowed additional limits to be imposed = based on some other criteria -- e.g., vimage membership. That strikes me = as a somewhat complex proposal that would bring new = performance/synchronisation concerns, so isn't necessarily something to = act on. However, the upshot is that, although I do not oppose combining = the zones, we should be aware that we're eliminating a form of resource = partitioning between vimages that we may want to find some other = solution for (ideally, an elegant one). Robert=