Date: Sun, 19 Aug 2001 11:53:10 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: David Greenman <dg@root.com> Cc: Sergey Babkin <babkin@bellatlantic.net>, hackers@FreeBSD.ORG, murray@FreeBSD.ORG, jkh@FreeBSD.ORG Subject: Re: Recommendation for minor KVM adjustments for the release Message-ID: <200108191853.f7JIrAP45731@earth.backplane.com> References: <200108181549.f7IFntw39740@earth.backplane.com> <20010818155924.D63814@nexus.root.com> <3B7F0F1E.45A25AC5@bellatlantic.net> <20010819025200.C76779@nexus.root.com>
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). Having a :>machine with a few gigs of memory and being able to use only 200MB :>for the buffer cache seems to be quite bad for a general-purpose :>machine. : : Uh, I don't think you understand what this limit is about. It's :essentially the limit on the amount of filesystem directory data that :can be cached. It does not limit the amount of file data that can :be cached - that is only limited by the amount of RAM in the machine. : :-DG : :David Greenman :Co-founder, The FreeBSD Project - http://www.freebsd.org :President, TeraSolutions, Inc. - http://www.terasolutions.com Yes, and the buffer cache determines how much dirty file-backed data (via write() or mmap()) the system is allowed to accumulate before it forces it out, which should probably be the greater concern here. The issue we face in regards to these limitations is simply that the kernel only has 1 GB of KVA space available no matter how much physical ram is in the box. We currently scale a number of things based on physical ram - sendfile() buffer space, buffer cache, swap meta space, kernel malloc area, PV Entry space, and so forth. Machine with large amounts of ram wind up eating up so much KVA that simple tuning elements such as increasing the number of NMBCLUSTERS or increasing 'maxusers' can cause the machine to run out of KVA space during the boot process, resulting in a panic. All I am suggesting here is that we throw in some reasonable limits temporarily (until we can come up with a permanent solution), limits which really only effect machines with greater then 1GB of real memory and which can be overriden by kernel options, in order to avoid common tuning configurations (e.g. large number of NMBCLUSTERS, high 'maxusers' specification) from causing unexpected crashes at boot time. This will give us time to come up with a more permanent solution. -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?200108191853.f7JIrAP45731>