Date: Sun, 19 Aug 2001 12:07:38 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Sergey Babkin <babkin@bellatlantic.net> Cc: David Greenman <dg@root.com>, hackers@freebsd.org, murray@freebsd.org, jkh@freebsd.org Subject: Re: Recommendation for minor KVM adjustments for the release Message-ID: <200108191907.f7JJ7cM45828@earth.backplane.com> References: <200108181549.f7IFntw39740@earth.backplane.com> <20010818155924.D63814@nexus.root.com> <3B7F0F1E.45A25AC5@bellatlantic.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108191907.f7JJ7cM45828>