From owner-freebsd-hackers Mon Jun 18 23:12:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 0844337B407 for ; Mon, 18 Jun 2001 23:12:38 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f5J6CaX25940; Mon, 18 Jun 2001 23:12:36 -0700 (PDT) (envelope-from dillon) Date: Mon, 18 Jun 2001 23:12:36 -0700 (PDT) From: Matt Dillon Message-Id: <200106190612.f5J6CaX25940@earth.backplane.com> To: "Ashutosh S. Rajekar" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: max kernel memory References: 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 :An associated question: along with this, changing the kernel to use only :PDEs should be better for TLB performance. Mapping 4Mb at a time would :definitely be much better than 4k. I'm talking of having the entire kernel :(at least the code) find mappings in the TLB, and keeping 4Mb mappings :might just do the trick. : :I did see pmap_kmem_choose() being called pretty early in :pmap_bootstrap(), but it looks like it's doing that for a single :page; what I want is to have 4M mappings for all pages in the system. : :Or have I overlooked something ? Any comments ? : :-ASR 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. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message