From owner-cvs-src@FreeBSD.ORG Tue Sep 12 05:26:02 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E99F116A4A7 for ; Tue, 12 Sep 2006 05:26:02 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 1487643D53 for ; Tue, 12 Sep 2006 05:26:00 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 36456 invoked from network); 12 Sep 2006 05:26:00 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 12 Sep 2006 05:26:00 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 12 Sep 2006 00:26:33 -0500 (CDT) From: Mike Silbersack To: Gleb Smirnoff In-Reply-To: <20060912001916.S43498@odysseus.silby.com> Message-ID: <20060912002456.I43498@odysseus.silby.com> References: <200609061356.k86DuZ0w016069@repoman.freebsd.org> <20060906091204.B6691@odysseus.silby.com> <20060906143204.GQ40020@FreeBSD.org> <20060906093553.L6691@odysseus.silby.com> <20060906150506.GA7069@rambler-co.ru> <20060911005435.A23530@odysseus.silby.com> <20060911142703.GF27667@FreeBSD.org> <20060912001916.S43498@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: rwatson@freebsd.org, src-committers@FreeBSD.org, Ruslan Ermilov , cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet in_pcb.c tcp_subr.c tcp_timer.c tcp_var.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2006 05:26:03 -0000 On Tue, 12 Sep 2006, Mike Silbersack wrote: > On Mon, 11 Sep 2006, Gleb Smirnoff wrote: > >> The UMA zone can't be made smaller than it is, while IP port ranges >> can vary in both directions. > > Hm, it can't be made smaller because we're using UMA_ZONE_NOFREE... why are > we using that? Shouldn't locking handle that, rwatson? :) Hm, it's been UMA_ZONE_NOFREE since day one. The reason may or may not be relevant after all the work rwatson has done with locking. But even if the actual backing memory is not freed, we can still reduce the max for the zone, thereby solving the ephemeral port shortage problem. We'll fail to free a few K of ram, but that's no big deal. Mike "Silby" Silbersack