Date: Fri, 13 Jul 2001 10:58:06 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: Leo Bicknell <bicknell@ufp.org>, hackers@FreeBSD.ORG Subject: Re: Network performance tuning. Message-ID: <3B4F36AE.857511FF@mindspring.com> References: <15.16ffaf54.287f3d4d@aol.com> <20010712135629.A49042@ussenterprise.ufp.org> <200107130128.f6D1SFE59148@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B4F36AE.857511FF>