From owner-freebsd-hackers Fri Jul 13 10:57:39 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.121.50]) by hub.freebsd.org (Postfix) with ESMTP id 45AE637B401 for ; Fri, 13 Jul 2001 10:57:37 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.130.157.Dial1.SanJose1.Level3.net [209.245.130.157]) by avocet.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id KAA02418; Fri, 13 Jul 2001 10:57:29 -0700 (PDT) Message-ID: <3B4F36AE.857511FF@mindspring.com> Date: Fri, 13 Jul 2001 10:58:06 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Dillon Cc: Leo Bicknell , hackers@FreeBSD.ORG Subject: Re: Network performance tuning. References: <15.16ffaf54.287f3d4d@aol.com> <20010712135629.A49042@ussenterprise.ufp.org> <200107130128.f6D1SFE59148@earth.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matt Dillon wrote: > This is fairly easy to do for the transmit side of things and > would yield an immediate improvement in available mbuf space. > For the receive side of things we can't really do anything > with existing connections (because we've already advertised > that the space is available to the remote end), but we can > certainly reduce the buffer space we reserve for new > connections. If the system is handling a large number of > connections then this sort of scaling will work fairly well > due to attrition. It's easy for the receive side, too: advertise smaller windows with early ACK's. > We can do all of this without ripping out the pre-allocation of > buffer space. I.E. forget trying to do something fancy like > swapping out buffers or virtualizing buffers or advertising more > then we actually have etc etc etc. Think of it more in terms of > the system internally sysctl'ing down the send and receive buffer > space defaults in a dynamic fashion and doing other reclamation to > speed it along. The problem is that the tcpcb's, inpcb's, etc., are all pre-reserved out of the KVA space map, so that they can be allocated safely at interrupt, or because "that's how the zone allocator works". Nothing you do will recover that KVA space for reuse, since zones are defined to be type-stable. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message