From owner-freebsd-hackers Sun Aug 19 12: 7:49 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 C8F6937B411; Sun, 19 Aug 2001 12:07:45 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7JJ7cM45828; Sun, 19 Aug 2001 12:07:38 -0700 (PDT) (envelope-from dillon) Date: Sun, 19 Aug 2001 12:07:38 -0700 (PDT) From: Matt Dillon Message-Id: <200108191907.f7JJ7cM45828@earth.backplane.com> To: Sergey Babkin Cc: David Greenman , hackers@freebsd.org, murray@freebsd.org, jkh@freebsd.org Subject: Re: Recommendation for minor KVM adjustments for the release References: <200108181549.f7IFntw39740@earth.backplane.com> <20010818155924.D63814@nexus.root.com> <3B7F0F1E.45A25AC5@bellatlantic.net> 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 : :David Greenman wrote: :> :> > - I would like to cap the size of the buffer cache at 200MB, :> > giving us another 70MB or so of KVM which is equivalent to :> > another 30,000 or so nmbclusters. :> :> That also seems like overkill for the vast majority of systems. : :But probably not for the large-memory systems (and on the machines :with small memory the limit will be smaller anyway). : :-SB I should also say that even in the Linux and Solaris worlds, systems with > 4GB of ram wind up being very specific-use systems. Typically such systems are used almost solely to run large databases. For example, so something like Oracle can manage a multi-gigabyte cache. These applications do not actually require the memory to be swap-backed, or file-backed, or really managed at all. In FreeBSD land the use-case would simply be our physical-backed-shared- memory feature. We could implement the 8-byte MMU extensions in the PMAP code as a kernrel option to be able to access ram > 4GB without having to change anything else in the kernel (not even vm_page_t or the pmap supporting structures) *IF* we only use the ram > 4GB in physical-backed SysV shared memory mappings. This would actually cover 99% of the needs of people who need to run systems with this much ram. There are lots of issues on IA32 in regards to memory > 4GB... for example, many PCI cards cannot DMA beyond 4GB. We would avoid these issues as well by only using the memory as physical backing store for SysV shared memory segments. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message