Re: Recommendation for minor KVM adjustments for the release
- 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. Ahh, thanks for the clarification. I retract my previous email about limiting this as well. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Recommendation for minor KVM adjustments for the release
: :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 [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Recommendation for minor KVM adjustments for the release
: :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 [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Recommendation for minor KVM adjustments for the release
: :There are two things I would like to commit for the release: : : - I would like to cap the SWAPMETA zone reservation to 70MB, :which allows us to manage a maximum of 29GB worth of swapped :out data. : :This is plenty and saves us 94MB of KVM which is roughly :equivalent to 30,000 nmbclusters/mbufs. : : It's seems really hard to justify even that much SWAPMETA. A more :reasonable amount would be more like 20MB. : : - 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. : : :-DG : :David Greenman It's not a 1:1 mapping. There is some sparseness to the way SWAPMETA structures are used so 29GB worth of swap-meta supported VM may wind up only being 15GB of actually-swapped-out-dat in reallity. It depends very heavily on the applications being run. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Recommendation for minor KVM adjustments for the release
On Sun, 19 Aug 2001, Matt Dillon wrote: : 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. 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. How hard would it be to allow dirty data in the file cache, without buffer mappings ? regards, Rik -- IA64: a worthy successor to i860. http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Recommendation for minor KVM adjustments for the release
There are two things I would like to commit for the release: - I would like to cap the SWAPMETA zone reservation to 70MB, which allows us to manage a maximum of 29GB worth of swapped out data. This is plenty and saves us 94MB of KVM which is roughly equivalent to 30,000 nmbclusters/mbufs. It's seems really hard to justify even that much SWAPMETA. A more reasonable amount would be more like 20MB. - 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. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Recommendation for minor KVM adjustments for the release
On Sat, Aug 18, 2001 at 08:49:55AM -0700, Matt Dillon wrote: - I would like to cap the SWAPMETA zone reservation to 70MB, which allows us to manage a maximum of 29GB worth of swapped out data. Not to introduce machine dependancy, but on Intel max ram is 4GB, so it seems to me that 8-12GB total space (4-8GB swap) would be an outside value. Alphas can have more RAM, although I doubt few do. Perhaps something like: max(4Gig, 3 * RAM) Would be the best calculation. I pitty the machine with 29 GB swapped, even if it has 4GB of RAM. -- Leo Bicknell - [EMAIL PROTECTED] Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Recommendation for minor KVM adjustments for the release
Leo Bicknell wrote: On Sat, Aug 18, 2001 at 08:49:55AM -0700, Matt Dillon wrote: - I would like to cap the SWAPMETA zone reservation to 70MB, which allows us to manage a maximum of 29GB worth of swapped out data. Not to introduce machine dependancy, but on Intel max ram is 4GB, No. I have a machine with 6GB in it waiting for finishing the PAE tweaks. Intel ppro, pentium2 and pentium3 has a maximum RAM of 64GB. Pentium4 may have more but I have not checked. Not that this matters so much. Machines with that much ram generally have a goal of zero paging/swapping, period. A cap sounds like a fine compromise to me. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Recommendation for minor KVM adjustments for the release
On Sat, Aug 18, 2001 at 06:34:43PM -0700, Peter Wemm wrote: No. I have a machine with 6GB in it waiting for finishing the PAE tweaks. Intel ppro, pentium2 and pentium3 has a maximum RAM of 64GB. Pentium4 may have more but I have not checked. It was my understanding from a previous thred that FreeBSD wasn't going to support this due to some problems it introduces, but I may be mistaken. -- Leo Bicknell - [EMAIL PROTECTED] Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Recommendation for minor KVM adjustments for the release
On Sat, 18 Aug 2001, Leo Bicknell wrote: On Sat, Aug 18, 2001 at 06:34:43PM -0700, Peter Wemm wrote: No. I have a machine with 6GB in it waiting for finishing the PAE tweaks. Intel ppro, pentium2 and pentium3 has a maximum RAM of 64GB. Pentium4 may have more but I have not checked. It was my understanding from a previous thred that FreeBSD wasn't going to support this due to some problems it introduces, but I may be mistaken. Nah, most of that thread consisted of people telling me FreeBSD would never support it because they didn't think it was worth their time to implement. But we all know that all it takes is one skilful person who thinks it's worth implementing and writes the code to support PAE ;) regards, Rik -- IA64: a worthy successor to i860. http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
