From owner-freebsd-hackers Tue Jun 19 0:56:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ip.eth.net (mail.ip.eth.net [202.9.128.18]) by hub.freebsd.org (Postfix) with ESMTP id EF6A037B403 for ; Tue, 19 Jun 2001 00:56:51 -0700 (PDT) (envelope-from asr@softhome.net) Received: (apparently) from vangogh.indranetworks.com ([61.11.16.239]) by ip.eth.net with Microsoft SMTPSVC(5.5.1877.467.46); Tue, 19 Jun 2001 13:26:21 +0530 Date: Tue, 19 Jun 2001 13:32:26 +0530 (IST) From: "Ashutosh S. Rajekar" To: Matt Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: max kernel memory In-Reply-To: <200106190612.f5J6CaX25940@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Mon, 18 Jun 2001, Matt Dillon wrote: > Don't worry about the MMU. Tests have shown that while 4MB pages are > nice, the performance boost is relatively minor. The kernel maps itself > using 4MB pages but normal 4K pte's are used for kernel allocations. > > What you are doing sounds interesting, and supporting lots of connections > certainly could require a great deal of kernel memory, but it all depends > on what you are *doing* with those connections. If you are acting as > a router you don't need much KVM. If you are acting as a diskless > (non-caching) web or tcp proxy then you do need KVM. If you are serving > web pages and the pages do not fit entirely in ram, you are likely to > hit disk I/O limitations long before you hit network/cpu limitations. > Etc. Well, we are building a web accelerator box called WebEnhance, that would support around a million TCP/IP connections (brag .. brag..). It would selectively function as a Layer 2/4/7 switch. And its going to run a kernel proxy, and probably nothing significant in user mode. It might be diskless or diskfull, depending on how much stuff real webservers throw at it. If the we can't realise addition of more memory for the kernel, then I can say that a disk-based cache or user level daemons acting as cache controllers are in the picture. I can make these assumptions about memory requirements: socket strucures: 200Mb mbufs + clusters: 400Mb TCP/IP PCBs : ??? HTTP requests+responses: 100-200Mb misc structures: 50Mb I can't imagine more than 10% of all connections to be in the active state at a given point in time - i.e. really sending and receiving data. I am not really worried about network/CPU limitations, even keeping a 100Mbps ethernet to full load is gonna be a challenge. Disks are really slow, so unless some sweeping algorithm is in place, it really means writing HTTP requests/responses all over the disk and latency, and along with it throughput becomes a big issue. -ASR --------------------------------------------------------------------- ("`-''-/").___..--''"`-._ (\ Indra Networks Pvt. Ltd `6_ 6 ) `-. ( ).`-.__.`) Pune, INDIA. (_Y_.)' ._ ) `._ `. ``-..-' mailto: asr@softhome.net _..`--'_..-_/ /--'_.' ,' http://www.rajekar.org (il),-'' (li),' ((!.-' http://www.indranetworks.com --------------------------------------------------------------------- There are no great men, buster. There are only men. -- Elaine Stewart, "The Bad and the Beautiful" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message