From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 07:54:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8512616A401 for ; Tue, 6 Feb 2007 07:54:47 +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 2650113C48E for ; Tue, 6 Feb 2007 07:54:47 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 96582 invoked from network); 6 Feb 2007 07:54:37 -0000 Received: from 209.68.2.70 (HELO localhost) (209.68.2.70) by relay00.pair.com with SMTP; 6 Feb 2007 07:54:37 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 6 Feb 2007 01:54:36 -0600 (CST) From: Mike Silbersack To: Randall Stewart In-Reply-To: <45B7631A.3070001@cisco.com> Message-ID: <20070206014950.S25997@odysseus.silby.com> References: <45B679F3.3080407@cisco.com> <20070124051050.A56064@xorpc.icir.org> <45B7631A.3070001@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Luigi Rizzo , freebsd-net Subject: Re: mbuf patch with sysctl suggestions too X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2007 07:54:47 -0000 On Wed, 24 Jan 2007, Randall Stewart wrote: > Well.. no I believe someone (was in Lin) mentioned that > you can get a live-lock if you allow a reduction.. and > thus the mbuf clusters were NOT allowed to be reduced.. I messed around with this a bit when changing the limit on net.inet.tcp.maxtcptw. It looked to me as if lowering the limit on a zone, even one that has UMA_ZONE_NOFREE, worked as expected. (As expected in the UMA_ZONE_NOFREE case was that the zone could not shrink below the maximum that was ever allocated in it.) I can see how problems could result if someone starts changing that setting while the system is in some sort of mbuf exhaustion state, but I think that the benefit of being able to tune it most of the time far outweighs the disadvantage of things going wrong in a few cases. Granted, I haven't even looked at your patch, so I could be missing something subtle. :) Mike "Silby" Silbersack