From owner-cvs-all@FreeBSD.ORG Tue Sep 12 05:21:17 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A33416A40F for ; Tue, 12 Sep 2006 05:21:17 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id D50CC43D58 for ; Tue, 12 Sep 2006 05:21:15 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 95670 invoked from network); 12 Sep 2006 05:21:14 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 12 Sep 2006 05:21:14 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 12 Sep 2006 00:21:47 -0500 (CDT) From: Mike Silbersack To: Gleb Smirnoff In-Reply-To: <20060911142703.GF27667@FreeBSD.org> Message-ID: <20060912001916.S43498@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> 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-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2006 05:21:17 -0000 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? :) > I think that your original commit should be rethought. It should free one > tcptw entry, in a case of absolute match, and return NULL. Do not jump > up and go on into cycle again. In order to do that, it has to know if the tcptw entry is one that will be useful for the upcoming connection. It might have to scan through many entries before it comes upon an entry, as your tests proved. It's still going to perform poorly in certain circumstances. Mike "Silby" Silbersack